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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp) . 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by Joint Technical Conmiittee (JTC) Broadcast of the European 
Broadcasting Union (EBU), Comite Europeen de Normalisation ELECtrotechnique (CENELEC) and the European 
Telecommunications Standards Institute (ETSI). 

NOTE: The EBU/ETSI JTC Broadcast was established in 1990 to co-ordinate the drafting of standards in the 
specific field of broadcasting and related fields. Since 1995 the JTC Broadcast became a tripartite body 
by including in the Memorandum of Understanding also CENELEC, which is responsible for the 
standardization of radio and television receivers. The EBU is a professional association of broadcasting 
organizations whose work includes the co-ordination of its members' activities in the technical, legal, 
programme-making and programme-exchange domains. The EBU has active members in about 
60 countries in the European broadcasting area; its headquarters is in Geneva. 

European Broadcasting Union 

CH-1218 GRAND SACONNEX (Geneva) 

Switzerland 

Tel: +41 22 717 21 11 

Fax: +4122 717 24 81 

The Digital Video Broadcasting Project (DVB) is an industry-led consortium of broadcasters, manufacturers, network 
operators, software developers, regulatory bodies, content owners and others committed to designing global standards 
for the delivery of digital television and data services. DVB fosters market driven solutions that meet the needs and 
economic circumstances of broadcast industry stakeholders and consumers. DVB standards cover all aspects of digital 
television from transmission through interfacing, conditional access and interactivity for digital video, audio and data. 
The consortium came together in 1993 to provide global standardisation, interoperability and future proof 
specifications. 

The present document is part 2 of a multi-part deliverable covering the Digital Video Broadcasting (DVB); IP Datacast: 
Program Specific Information (PSI)/Service Information (SI), as identified below: 

Part 1 : "IP Datacast over DVB-H" ; 

Part 2: "IP Datacast over DVB-SH". 



Introduction 

The contents of the present document specify the use of PSI and SI tables and related descriptors in DVB-SH networks, 
and more generally of all signalling elements relevant to the usage of DVB-SH network (TPS, Signalling Field, SHIP). 
TS 102 470-1 [8] is a corresponding document describing usage of PSI/SI information in IPDC in 
DVB-H systems. 

The present document describes how the network infrastructure SHALL generate the signalling. In some cases, the 
behaviour of the receiver is also specified. More general description of receiver behaviour and not-directly PSI/SI 
related signal generation is FFS in DVB-SH the implementation guideline. 
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The use of PSI/SI tables and/or descriptors not mentioned within this clause is either not restricted for any particular 
network and specifying the use of such tables/descriptors is either outside of the scope of the present document, or can 
be applied for both DVB-H and DVB-SH networks and therefore can be found in [8]. 

Clause 4.1 provides some introduction to the PSI/SI in DVB-SH. 

Clause 4.2 specifies content regionalization concept within a "partially available TS". 

Clause 4.3 specifies MPE usage. 

Clause 4.4 specifies the descriptors required and their usage. 

Clause 4.5 specifies the PSI tables usage. 

Clause 4.6 specifies the SI tables usage. 

Clause 4.7 specifies the TPS and Signalling Field parameters and their usage. 

Clause 4.8 specifies the Update Notification Table usage. 

Clause 4.9 specifies the INT announcement usage. 

Clause 4.10 specifies SHIP usage. 

Clause 4.11 specifies the signalling field usage. 
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1 Scope 

The present document provides focus on PSI/SI tables and descriptors used in DVB-SH Systems. 

Used tables and descriptors are introduced, and their usage is described. 

The present document defines the set of PSI/SI data a DVB-SH Receiver may expect to be available on a DVB-SH 
bearer (data transmission baseband) and the DVB-SH Network is expected to make available on the DVB-SH Bearer. 



2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• Non-specific reference may be made only to a complete document or a part thereof and only in the following 
cases: 

if it is accepted that it will be possible to use all future changes of the referenced document for the 
purposes of the referring document; 

for informative references. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 

[1] ETSI EN 300 468: "Digital Video Broadcasting (DVB); Specification for Service Information (SI) 

in DVB systems". 

[2] ETSI EN 301 192: "Digital Video Broadcasting (DVB); DVB specification for data broadcasting". 

[3] IETF RFC 1 112: "Host extensions for IP multicasting". 

[4] IETF RFC 2464: "Transmission of IPv6 Packets over Ethernet Network". 

[5] ETSI TS 102 585: "Digital Video Broadcasting (DVB); System Specifications for Satellite 

services to Handheld devices (SH) below 3 GHz". 

[6] ETSI EN 302 583: "Digital Video Broadcasting (DVB); Framing Structure, channel coding and 

modulation for Satellite Services to Handheld devices (SH) below 3 GHz". 

[7] ETSI TS 102 594: "Methods for Testing and Specification (MTS); Internet Protocol Testing (IPT): 

IPv6 Security; Conformance Abstract Test Suite (ATS) and partial Protocol Implementation eXtra 
Information for Testing (PIXIT) proforma". 

[8] ETSI TS 102 470-1 (VI. 1.1): "Digital Video Broadcasting (DVB); IP Datacast: Program Specific 

Information (PSI)/Service Information (SI); Part 1: IP Datacast over DVB-H". 
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2.2 Informative references 



The following referenced documents are not essential to the use of the present document but they assist the user with 
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including 
any amendments) applies. 

[i.l] ETSI TR 101 21 1 (VI. 10.1): "Digital Video Broadcasting (DVB); Guidelines on implementation 

and usage of Service Information (SI)". 



3 Definitions and abbreviations 

3.1 Definitions 

3.1.0 Introduction 

For the purposes of the present document, the following terms and definitions apply (only those definitions which are 
specific to the present document and complementary to the definitions found in TS 102 470-1 [8] are listed here). In 
addition, definitions have been classified according to their nature and scoping in three categories: infrastructure, 
transport containers, tables and signalling structures. 

3.1.1 Infrastructure 

DVB-SH: transmission system targeted to provide IP-based services to handheld terminals over hybrid global and local 
radio channels, as defined in EN 302 583 [6] and EN 301 192 [2] 

DVB-SH bearer: link and physical layers into which IP packets are encapsulated according to DVB-SH specifications 

DVB-SH receiver: equipment or system can receive IP based services provided over a DVB-SH bearer 

DVB-SH region: group of cells transmitting same content on a partially available TS 

DVB-SH distribution network: network that transports a TS from a central head-end to a network of DVB-SH 
repeaters 

NOTE 1: The distribution network includes: 

the gateways, both at central (transmission gateway) and remote (reception gateway) places; 

the network itself, usually a satellite and/or an IP network. 
NOTE 2: We distinguish between global and a local distribution network, depending on the coverage requirements: 

global distribution network enables to reach all repeaters (e.g. via a satellite coverage); 

whereas a local distribution network enable reach of only a subset of the repeaters. 

DVB-SH adaptation: function of customizing a "complete TS" to a region while preserving the PSI/SI identification 

NOTE 1 : TS_id is kept the same, only content is locally removed and this is signalled by using 
service_availability_descriptor. 

NOTE 2: More generally SI tables are kept unique and identical in all regions, PSI are specific to each region. 

NOTE 3: This adaptation function can be performed either on the head-end (central adaptation) or on the repeater 
(remote adaptation). The content removal can be done at SH or DVB service level. 

DVB-SH {adaptation; distribution}: function combining together DVB-SH adaptation and distribution 

NOTE 1: Different options are possible among which "adapt then distribute" and "distribute then adapt". Order can 
therefore vary between both elements so this common definition enables to describe all cases more 
generically. If needed the adapter/distribution element can be identified individually. 
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NOTE 2: The combination of both functions is not specified and left to implementation. However interfaces to and 
from these combined functions are specified. 

DVB-SH adapter: equipment performing the DVB-SH adaptation function 

DVB-SH head-end: group of equipments in charge of generating a SH-compliant TS and interfacing it with a 
distribution network 

NOTE 1: A DVB-SH head-end can have a SH adaptation function in case of central adaptation. 

NOTE 2: We distinguish between a global and a local head-end depending on the type of distribution network to 
which the head-end is connected. 

DVB-SH modulator: function that takes at its input a SH-compliant TS with its SHIP signalling and modulates it 
according to DVB-SH waveform standard [6] 

NOTE: The modulator synchronizes itself using a SHIP MPEG2 packet. 

DVB-SH repeater: equipment in charge of modulating a TS according to DVB-SH physical waveform [6] 

NOTE: By nature, this equipment includes a DVB-SH modulator. In addition, it MAY include: 

a DVB-SH distribution reception gateway in case the repeater is not co-located with the 
DVB-SH head-end; 

a DVB-SH adapter in case of remote adaptation (see figure 3). 

DVB-SH network: DVB network that conveys DVB-SH bearers to DVB-SH receivers 

NOTE: The DVB-SH network is composed of the infrastructure and the receivers. A generic overview of the 
DVB-SH infrastructure is presented in figure 1. Various options are also presented in figures 2 and 3. 
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Figure 1 : DVB-SH infrastructure synoptic 
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Figure 2: DVB-SH infrastructure in case of central adaptation 
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Figure 3: DVB-SH infrastructure in case of remote adaptation 



ETSI 



11 



ETSI TS 102 470-2 VI. 1.1 (2009-12) 



3.1.2 Transport containers 

SH service: fraction of the MPEG2 TS signalled to the modulator via the SHIP 

NOTE: A SH service is an entity that can be processed by a modulator. SH service can be used for filtering 
purpose and regionalization. 

Partially available DVB/SH service: DVB/SH service that is not present in all cells where the TS is modulated 

NOTE 1 : DVB service presence is informed by the service_availability_descriptor in SDT whereas the SHIP 
informs SH service presence. 

NOTE 2: A partially available DVB/SH service carries local content. A synonym of a paDVB/SH service is a local 
DVB/SH service. 

Common DVB/SH service: DVB/SH service that is present in all cells where the TS is modulated 

NOTE 1 : DVB service presence is informed by the service_availability_descriptor in SDT whereas the SHIP 
informs SH service presence. 

NOTE 2: A common DVB/SH service carries common content. There can be zero, one or more of such common 
DVB/SH services in a given TS. 

Partially available TS: TS that signals in the PSI/SI one or more partially available DVB/SH service(s) 

NOTE: This definition has nothing in common with the partial TS referred by the partial TS descriptor in [1]. 

Complete TS: partially available TS where all signalled services, including the paDVB/SH ones, are actually present 

NOTE: Complete TS has to be considered for generating the PSI/SI information coherently (in particular the SI 

that is required to be unique). However complete TS MAY not actually exist in the network as such and is 
only conceptually present for supporting the signalling generation. Complete TS MAY not be appropriate 
for actual transmission over the air. 

Regionalized TS: partially available TS where not all signalled services are actually present 

NOTE: We distinguish between the "global regionalized TS" (aka "global TS") where only the common services 
are present, and the "local regionalized TS" (aka local TS) where only the common services and a fraction 
of the local are present. 



Partially available TS 




Complete TS 



Ffegionalized TS 




Figure 4: Partially available TS tree definition 

IP/MAC notification service: DVB service with a component carrying one or more INT sub_tables 
IP/MAC partially available notification service: IP/MAC notification service that is partially available 
MPE-IFEC section: private section as specified in EN 301 192 [2] 
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3.1.3 Tables 

NIT_actual: NIT sub_table describing the actual delivery network. NIT_actual has table_id value 0x40 
NIT_other: NIT sub_table describing the other delivery network. NIT_other has table_id value 0x41 
INT deferred notification NIT: NIT sub_table containing a linkage_descriptor with linkage_type OxOC 
INT notification NIT/BAT: NIT or BAT sub_table containing a linkage_descriptor with linkage_type OxOB 
IP/MAC notification table: sub_tables as defined in EN 301 192 [2], clause 8.4.3 

3.1 .4 Signalling structures 



3.1.4.1 



For NIT & BAT 



IP/MAC notification link structure: structure defined in EN 301 192 [2], clause 8.2.1 and used in the direct 
linkage_descriptor inside BAT or NIT, when linkage_type is set to OxOB 

Deffered IP/MAC notification link structure: structure defined in EN 301 192 [2], clause 8.2.2 and used in the 
deferred linkage_descriptor inside NIT, when linkage_type is set to OxOC 



3.1.4.2 



For SDT & PMT 



IP/MAC notification info structure: structure defined in EN 301 192 [2], clause 8.3.1 and used by the PMT related to 
the IP/MAC notification service inside the data_broadcast_id_descriptor, when data_broadcast_id is set to OxOB 

multiprotocol encapsulation info structure: structure defined in EN 301 192 [2], clause 7.2.1 and used by SDT in 
data_broadcast_descriptor and PMT in data_broadcast_id_descriptor, when data_broadcast_id is set to OxOB 



3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

BAT Bouquet Association Table 

CA Conditional Access 

CAT Conditional Access Table 

CRC Cyclic Redundancy Check 

DVB Digital Video Broadcasting 

EIT Event Information Table 

ES Elementary Stream 

EEC Forward Error Correction 

FES For Further Specification 

EFT Fast Fourier Transform 

INT IP/MAC Notification Table 

IP Internet Protocol 

IPDC IP Datacasting 

IPv4 Internet Protocol, version 4 

IPv6 Internet Protocol, version 6 

Mbps Mega bits per second 

MPE Multi-Protocol Encapsulation 

MPEG Moving Picture Expert Group 

MPE-IFEC MPE Inter-burst Forward Error Correction (DVB-SH) 

NIT Network Information Table 

OFDM Orthogonal Frequency Division Multiple Access 

PA Partially Available 

PAT Program Association Table 

paTS partially available TS 

PID Packet IDentifier 

PMT Program Map Table 

PSI Program Specific Information 
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RST Running Status Table 

SDT Service Description Table 

SFN Single Frequency Network 

SH Satellite to Handheld 

SHIP SH frame Information Packet (DVB-SH) BROADCAST 

NOTE: SeeTS 102 585 [5]. 

SI Service Information 

ST Stuffing Table 

TDM Time Division Multiplex 

TDT Time and Data Table 

TOT Time Offset Table 

TPS Transmission Parameter Signalling 

TS Transport Stream 

TSDT Transport Stream Description Table 



4 PSI/SI IG for DVB-SH Systems 

4.1 Introduction to PSI/SI (informative) 

PSI/SI usage for DVB-SH does not significantly deviate from the PSI/SI usage for DVB-H as specified in 
TS 102 470-1 [8]. In the particular case of SFN or in non-SFN when exactly same capacities are available on the 
different frequencies, the DVB-SH and DVB-H PSI/SI usages match on large extents so that they can even share the 
same introduction clauses 4.1.1 and 4.1.2. 

In that latter case, the difference between DVB-SH and DVB-H mainly relies on the usage of descriptors needed for 
supporting signalling of SH novelties such as physical parameters (via SH_delivery_system_descriptor), MPE-IFEC 
(via time_slice_fec_identifier_descriptor) and their usage in the NIT and INT. These differences are described in the 
relevant clauses 4.4 (descriptors) and 4.6 (SI Tables). 

However, a new concept called "content regionalization" can be provided by SH on the same TS (then called a 
"partially available TS") in some specific non-SFN modes (SH-B and SH-A non-SFN). The principle is that the actually 
transmitted content in the TS varies depending on the transmission location (cell_id) while preserving the SI, therefore 
simplifying hand-overs between satellite and terrestrial regions because the terminal does not need to parse SI each and 
every time. This concept therefore induces some impact on the PSI/SI side and needs special introduction in clause 4.2. 

4.1 .1 PSI/SI and DVB network (SFN and non SFN with same capacities 
on different frequencies) 

This clause is same as clause 4.1 in TS 102 470-1 [8]. 

4.1 .2 IP platform; IP flow and IP stream (SFN and non SFN with same 
capacities on different frequencies) 

This clause is same as clause 4.2 in TS 102 470-1 [8]. 

4.2 Content regionalization in SH networks (non-SFN with 
different capacities on different frequencies) (normative) 

This clause describes how content can be regionalized on a TS sent over a SH network on a hybrid frequency in a 
non-SFN context with different transmission capacities between satellite and terrestrial transmitters, while the latter are 
all SFN synchronized together. In such conditions, the terrestrial transmitters support different, and in general, increased 
capacity compared to satellite transmitter. Local content can therefore be injected in the different terrestrial cells in 
addition to the common satellite content repeated locally. 
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In order to prevents the terminal from parsing non-real time signalling (the SI) each time it performs a hand-over 
between a satellite and a terrestrial cell, a common SI is generated and transmitted in all cells and has to be acquired 
only once, real-time signalling (PSI) being the only location-dependent signalling to be acquired at each hand-over. 

A "complete TS" is therefore defined in order to support SI unicity. Only the signalling part of the "complete TS" (to 
ensure unicity of signalling) SHALL be generated, other parts of complete TS (such as MPE data) is left to 
implementation. "Local TS" are the actual TS being modulated with the same SI as the "complete TS" but with their 
own specialized PSI. Since local TS are the ones to be actually modulated, these "regionalized TS" SHALL be fully 
generated in a mandatory way with the signalling and data). Therefore the interfaces between {adaptation; distribution} 
function on one side, and modulation on the other side is mandated, {adaptation; distribution} functions themselves are 
not mandated and left open to implementation. 

4.2.1 TS construction using time-slice bursts, DVB and DVB-SH services 



4.2.1.1 



Generalities (normative) 



One particularity of SH networks is the possibility to provide content regionalization inside the same TS in the non-SFN 
case (global signal is not modulated on the same frequency as the local signal). The regionalization concept is 
summarized in figure 5. 



TS_idl (all services^ 



Adaptation 

& 
distribution 




Mandatory for the signalling Left open to implementation Mandatory for the modulation 

Figure 5: Service regionalization concept 

It can be seen in this figure that regionalization is performed in 3 main steps: 

• Step 1: A master "complete TS" is generated that signals all services on the PSI/SI level. Therefore PSI/SI 
coherence is ensured between all regionalized TS. 

• Step 2: This "complete TS" is then distributed and adapted to all modulators of the system (the common and 
local ones). The adaptation function consists mainly in filtering out the content that does not pertain to the 
location. The order of operations performed during this step is left open to implementation. Different 
approaches are possible for performing this step. 
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One implementation illustrated in figure 6 consists in "distributing then adapting". This approach is better suited for 
local re-multiplexing cases where more flexibility (and therefore more complexity) is required at the repeater level. In 
particular, advanced processing at section level can be done on the common satellite service repeated locally to avoid 
duplication of unnecessary MPE-IFEC sections, or enable replacement of satellite MPE-IFEC sections with 
complementary sections: 

• The "complete TS" is distributed to the different repeaters as it is with all services actually included. Individual 
services are transported only once over the distribution network. Content can be distributed over a global or a 
local distribution network, depending on the coverage requirements. 

• Inside each repeater an adaptation function creates a "regionalized TS" that is syntactically correct and where 
all PSI/SI tables are re-multiplexed along with SHIP and MPE signalling. PSI/SI are however still coherent 
between all the "regionalized TS" (the SI being the same), therefore a receiver catching local regionalized TS 
can learn the unique SI, about non-present neighbour or foreign local services. 

• This regionalized TS is subsequently modulated. 



TSJdl 




Global 
^ Distribution 
Network 



TSJdl 




Local 

Distribution 

Network 




Mandatory for the signalling ^^ distribution then adapt » approach Mandatory for the modulation 

Figure 6: "Distribute then adapt" approach 

Another implementation illustrated in figure 7 consists in "adapting before distributing". This approach is better suited 
for cases where local re-multiplexing can be avoided and where a central head-end can pre-process all signalling: 

• The "complete TS" is adapted inside the head-end where all "regionalized TS" individual or complete parts 
can be pre-computed in the form of individual or group of DVB/SH service(s), further called a 'part'. 

• Each part is distributed to the relevant repeaters. Different distributions means are possible. As an example, 
each part could be carried within a different PID (PID_1 for "global regionalized TS" part common to all 
repeaters, PID_2 for "local regionalized TS" specific part to region 1, PID_3 for "local regionalized TS" 
specific part to region 2. . .). A local repeater in region X will then need to select PID_1 and PID_(X+1) to 
create the complete "regionalized TS". If more transport granularity is required between two regions, more 
PID can be used to factorize the parts in common between different regions. More details on such a transport 
implementation is out of scope of the present document. 

• Inside each repeater the modulator is in charge of stacking the different parts by appending them for 
subsequent modulation. 

• The head-end can be split into a global and a local head-end where most of the common signalling is being 
processed at the central head-end and only the local signalling is being processed in the local head-end. More 
details on this approach is out of scope of the present document. 
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Mandatory for the signalling « adapt then distribute » approach Mandatory for the modulation 

Figure 7: "Adapt then distribute" approach 

• Step 3: the regionalized TS are modulated. The modulator located behind the adapter receives canonical TS. 
Depending on the cell to which they belong, these modulators therefore receive only a fraction of the 
"complete TS" services inside the "regionalized TS" with a coherent signalling between all the different 
"regionalized TS". SHIP is used to synchronize the modulators together. 

NOTE 1: Regulatory constraints MAY impose all local repeaters to repeat the common services. In addition to 
these common service, local repeaters MAY also modulate local contents specific to the cell to which 
they belong. 

Each "regionalized TS" is a syntactically correct TS so that a receiver receiving this only TS can process the signal and 
learn on a service absence and its regionalization. In some circumstances, the terminal can receive several "regionalized 
TS" from the same "complete TS" (for instance the common and one local ones). If the network configuration and the 
terminal capacity enable it, the two "regionalized TS" can be combined together to provide more reception quality on 
the common content. 

NOTE 2: This improvement is always optional, a terminal being always able to switch from one "regionalized TS" 
to another without benefiting from the complementary reception. 

Different options are possible for performing service filtering during adaptation: this can be done at SH or DVB service 
layer: 

• At SH services layer, the adapter selects one or several SH services from the "complete TS" as signalled by the 
SHIP carried inside each SH frames. The downstream repeater will then modulates the only selected SH 
services and will align them within the SH frame. At the receiver side, these SH services are identified by the 
EFRAME sequence number. For the common services, the quality MAY be improved by recombining the 
EFRAMES from both "regionalized TS" in the terminal using code diversity. These principles are more 
detailed in clause 4.2.1.3. 

• At DVB service layer, the adapter selects only the relevant Elementary Streams from the "complete TS". 
PSI/SI tables are recomputed. At the receiver side it is then not possible to combine the EFRAMES of the 
common content from the different paths since the individual bits received on satellite and terrestrial paths 
MAY differ. However, some combination is still possible at MPE and MPE-IFEC section level: 

For the common services, missing MPE sections on one path COULD be received on the other path. 

Additionally if MPE-IFEC is used, different MPE-IFEC sections COULD be received via the different 
paths and combined inside the same decoding matrix by the terminal. This code combining option if 
FES. 
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4.2.1.2 



Impact on PSI/SI (normative) 



In all cases PSI/SI homogeneity is ensured since the same complete TS identification is used on all regionalized TS (in 
particular SI are unique). The DVB service granularity is used to provide consistent regionalization information 
whereby one DVB service MAY belong to, one (e.g. one local content cell), several (e.g. several local cells) or all cells 
(e.g. common content case). In figure 8, a possible logical DVB object hierarchy is presented: 

• One IP encapsulator delivers the complete "complete" TS where all (time-sliced) services are present, usually 
in individual elementary streams. 

• These elementary streams are mapped in DVB services that are logically connected to individual cells: the 
presence of one DVB service in one cell is signalled via the SDT service_availability_descriptor. Therefore a 
DVB service is a logical container for regional distribution. 

• If the content regionalization is performed at the SH service layer, the DVB services are in addition mapped on 
SH services using SHIP signalling so that adapters can perform filtering using SH frames and produce a 
"regionalized TS" (either local or common) by removing those SH services from the "complete TS" that are 
not present in the cell, and keeping those that are present. Possible update MAY occur on the local SH services 
(section header real-time parameters adaptation, PSI reprocessing, SHIP update. . .). 

• If the content regionalization is performed at DVB service layer, the DVB services are simply removed from 
the "complete TS" at the level of the elementary stream. In addition a number of operations are performed 
(section header real-time parameters adaptation, PSI/SI reprocessing, SHIP update. . .) and the common service 
can be further optimized since no physical combination is requested between the satellite and the terrestrial 
paths. 
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Figure 8: Transport stream with regionalized content and related DVB object hierarchy 

4.2.1 .3 Filtering at SH service layer (informative) 

Due to the specificity of SH service filtering, a special zoom is given on this case. When the filtering is performed at SH 
service layer, the "complete TS" different layers look like figure 9. 
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Figure 9: Content regionalization signalling 
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It can be seen figure 9 that: 

• Time-slicing signalling is done at the MPE level using the real-time parameters of the MPE headers. 
MPE-IFEC sections MAY also be carried. 

• MPEG2 TS level signalHng is done via the PSI/SI; for instance the PMT, PAT and SDT signal to which DVB 
services the different elementary streams belong and in which cells the DVB services are located. In the 
example of figure 9, the elementary streams CiJ of DVB service "i" share the same colour and are timely 
grouped together. They will be modulated on the same cells. 

• DVB-SH level signalling is done by the SHIP packets inserted in each and every SH frame; the SHIP packets 
signal what and when the next SH service starts in the next SH frame. When content regionalization is 
performed, the DVB services MUST match the SH services, id-est a DVB service MUST be completely 
located inside a SH service. 

Based on this signalling, the SH service filtering is performed by the {adapter; distribution} differently depending on 
the cell where the repeater is located and on the distribution method: 

• In all cases, the global {adapter; distribution} keeps only one DVB service (e.g. the service 1) and distribute it 
to all repeaters. 

• In the "transmit and adapt" method, one local adapter keeps the common service by regulatory constraint 
(service 1) and possibly one or more additional local service(s) (e.g. service 2 or 3) that are transmitted to the 
modulator so that this latter can transmit both services as exemplified in figure 10. 

• In the "adapt and transmit" method, one local adapter keeps the complementary local service(s) (e.g. service 2 
or 3) and distributes them in individual parts to the modulator where they are combined with the common part 
in order to form the "regionalized TS" as exemplified in figure 11. 

This is described in more details below. 
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Figure 10: SH service filtering principle using "transmit and adapt" method 
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Figure 1 1 : SH service filtering with "adapt and transmit*' method 
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The IP encapsulator constitutes the "complete TS" with following design criteria: 

SHIP signals SH services for regionalization purpose, at least one SH service for each region. The SH 
services are repeated with a specific repetition_interval. SH services are timely grouped so that all SH 
services MUST be found during each repetition_interval. 

As required for subsequent per-SH frame alignment, SH services MUST be aligned with SH frames 
following these rules: 

■ Beginning of the first SH service of one region MUST match beginning of a SH frame. 

■ However if there are more than one SH service in this region, the remaining SH service(s) are not 
required to match this criteria. 

■ As a consequence repetition_interval is a multiple of the SH-frames duration used in the global 
"regionalized TS". 

There is one SHIP per SH-frame whose size depends on the actual modulation parameters: 

■ SH frame capacity in the common SH service is based on the global modulation; this capacity is 
computed from the modulation characteristics (see for instance [6], table 5.11 for OFDM case 
and [6], table 5.12 for TDM case) and the chosen code rate and is expressed in units of EFRAMES 
that carries 8 MPEG2 TS. 

■ SH frame capacity in the local SH service is a complementary capacity that comes in addition to 
the global capacity. Therefore SH frame size MAY differ between the common and local SH frame 
capacities. 

Note that the above time-slice bursts need not be aligned with this repetition_interval. However in case 
power saving is sought with a class 2, time-slice burst MUST be aligned with SH frames as 
recommended in [7], clause 7.2.3.3.1. 

The {adapter; distribution} create and distribute the "regionalized TS" for subsequent modulation by the 
modulator: 

To create the global "regionalized TS", the {adapter: distribution} has to excerpt the common SH service 
(e.g. service 1). A valid SHIP is already present in every SH frame constituting the SH service that can 
be used by the global modulator to synchronize the global SH frame with the local ones. 

To create the local "regionalized TS", the {adapter; distribution} has to excerpt the SH service 1 and the 
local SH service (e.g. SH service 2) and merge both together. The merging of the global and local SH 
frames is done in such a way that only one valid SHIP is present in every SH frame, enabling the 
modulator to synchronize the local SH frame with the global SH frame and with other repeaters of the 
same terrestrial SFN cell. The merging is therefore achieved at the level of each and every SH frame, 
each SH frame bearing a common part that can be code-combined between the two "regionalized TS", 
and a local part that is present only on the local "regionalized TS" (see clause 4.2.1.4 for more 
information on receiver behaviour). 

The modulator receives a valid SH frame: 

The resulting SH frame is received at a bit rate equal to the actual radio capacity. Therefore, thanks to the 
SHIP, the modulator can apply the usual processing for synchronization. 

Note that the terrestrial modulator will receive two SHIP in each SH-frame, one in the common part and 
one in the local part, only one (the one in the local part) being valid. 

This synchronization is important since both SH frames on the two "regionalized TS" need to be aligned 
by the two modulators before transmission. The procedures for doing such an alignment can be found in 
clause [7], clause 7.2.3.4. 
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4.2.1 .4 Receiver behaviour with SH service layer filtering (informative): 

First at cold start, terminal acquires PSI/SI. In particular, the terminal resolves the global path for the elementary stream 
of interest. It also resolves availability of the DVB service where the elementary stream is located. Additionally, the 
terminal MUST acquire via the received SHIP the map of the SH services. The structure of the SH services is repeated 
regularly in the common part using service_synchronization_function (see [6], clauses A.4.9 and 4.2.10.2.5). 

We assume that the receiver has acquired non-real time information whereby the receiver has an exact map of SH 
services and DVB services availability per cell_id: 

From SHIP cell_id and servicejocalization functions, the receiver can map on which cells local SH services 
are being transmitted (see clause 4.10.2 for more details). We assume in the following that there is a unique 
common SH service with an id set to '0'. 

From SDT service_availability_descriptor, the receiver has knowledge of the availability of DVB services on 
each cell (see clause 4.4.3). 

In this example, we assume the receiver is interested by a service carried within SH service '0': 

If the receiver can receive both "regionalized TS" : 

On satellite signal, receiver wakes up at time signalled by previously received delta-t whereas on 
terrestrial signal, receiver wakes up at time signalled by updated delta-t (see clause 4.3). 

Receiver coarsely aligns each received SH-frame since SH frames are timely aligned (see [6], 
clause 5.5.2.2). 

Receiver localizes common SH service '0' on both "regionalized TS". This can be achieved by different 
means: 

If the receiver maintains a precise time and frequency clock, it can predict start of the SH frame and 
SH service (see [7], clause 7.5.3.3). 

When the first EFRAME has been decoded, the receiver can compare CBCOUNTER_SH that is 
related to the SH service number (see [6], clause 5.1.2). 

When a SHIP is received, it can signal the start of a service in the next SH frame. If the SHIP 
indicates the start of service '0' in the next SH frame, the receiver can derive immediately the 
beginning of the common service. 

Inside the SH service '0', EFRAMES can be compared one to one using CBCCOUNTER_FB. 

Receiver decodes current EFRAME with soft bits information coming from both modulation paths as 
explained in [7], clause 7.2.2.3. 

If the receiver can receive only one "regionalized TS", receiver only decodes EFRAMES individually: 

Receiver wakes up are time signalled by delta-t. See clause 4.3 for more information. 

Receiver decodes current EFRAME with soft bits information coming from a unique modulation 
scheme. 

Similar approach (as the reception of a unique "regionalized TS") would be applied for a local SH service. 

4.2.2 Filtering at SH service level 
4.2.2.1 Recommendations (normative) 

4.2.2.1.0 Introduction 

We give recommendation of the complete TS attributes in clause 4.2.2.1.1, then we describe how filtering is achieved in 
clause 4.2.2.1.2, then we give the result of the filtering in the form of the regionalized TS attribues in clause 4.2.2.1.3. 
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4.2.2.1 .1 "Complete TS" attributes 

4.2.2.1.1.1 Introduction 

We describe first the common SH services then the local SH services attributes. 

4.2.2.1 .1 .2 Common SH service attributes 

4.2.2.1.1.2.1 Introduction 

NOTE: As a consequence of common service repetition in all "regionalized TS", the requirements applying to the 
common SH service are also valid for common SH services in all regionalized TS (see clause 4.1.2.1.3.1). 

4.2.2.1 .1 .2.2 Mandatory SHIP parameters 

Mandatory SHIP parameters are pertinent for the actual regionalized TS where this SHIP is valid. Since SHIP present in 
the common service MUST have a synchronization_id set to T and be valid for the satellite cell, the SHIP therefore 
conveys radio parameters corresponding to the satellite cell. 

NOTE 1 : SHIP having a synchronization_id set to '0' are valid for the terrestrial cells and therefore convey radio 
parameters corresponding to the terrestrial cell. They cannot be located in common SH service unless 
there is no satellite cell at all. 

NOTE 2: If different radio parameters are to be used with the same TS (for instance transmitting the TS over 

different satellite cells while maintaining the same bit rate, e.g. by modifying the EFT in DVB-SHA) only 
one set of real-time parameters can actually be fixed in the SHIP. However the SHIP in the regionalized 
global TS can be updated to reflect the updated SHIP values inside each cell. 

NOTE 3: Since the complete TS is not made for actual modulation (only the local TS is made for) there is no real 
consequence on the fact that all radio parameters are not reproduced in the SHIP real time parameters. 

4.2.2.1 .1 .2.3 Optional SHIP parameters 

In general, optional functions SHOULD be conveyed in SHIP located in the common SH service. In particular, 
functions describing content localization such as cell_id, service_localization, service_synclironization MUST be 
located in the common SH service. Some exceptions are listed in the local service attribute (clause 4.2.2.1.1.3.2). 

If an optional function conveyed by the SHIP packet spans several successive SHIP, the function SHOULD be 
completely described within current common service or, otherwise stated, part of the function SHALL not be 
distributed in other services than the common one. 

If it is not possible to convey the function within the current common service, then the following SHIP conveying the 
remaining of the function SHALL be located in the next iteration of the common service. Therefore no part of an 
optional function starting in the common service SHALL be located in the local part. 

The procedure for supporting transmission of optional SHIP parameters over several SHIP packets is defined in 
clause 4.10.2.1. 

4.2.2.1.1.2.4 PSI/SI tables 

When present, the BAT, TOT, UNT, CAT, TSDT MUST be located in the common SH service only. 

The NIT, SDT, TDT SHALL be sent in the common SH service only. 

Other tables (EIT, RST, ST) are ignored and SHOULD not be transmitted. 

The INT SHALL be sent in the common SH service only. 

All tables sent in the common service SHALL be received in all cells. 
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PAT and PMT must be inserted in the common SH service according to regular repetition frequency. Their content is 
according to clause 4.2.2.1.2.2: 

• The PAT MUST signal all DVB services present in the complete TS. 

• All PMT corresponding to DVB services present in the complete TS MUST not be void. 

4.2.2.1 .1 .3 Local SH service attributes 

4.2.2.1 .1 .3.1 Mandatory SHIP parameters 

Mandatory SHIP parameters are always pertinent for the actual regionalized TS where this SHIP is valid. Since SHIP 
present in the local service MUST have a synchronization_id set to '0' and be valid for the terrestrial cell, the SHIP 
therefore conveys pertinent radio parameters corresponding to the terrestrial cell. 

NOTE 1: SHIP having synchronization_id set to T do not belong to a local SH service but to the global SH service, 
are not valid in the regionalized TS and are to be ignored with regards to their conveyed mandatory 
parameters. 

NOTE 2: if there are different terrestrial radio parameters but leading to same bit rates (such as EFT size 

variations), only one set of parameters can be signalled in the mandatory parameters of the local SHIP of 
the complete TS. Local variations are to be reflected in the local SHIP of the different regionalized TS 
(see clause 4.2.2.1.2.1). 

4.2.2.1 .1 .3.2 Optional SHIP parameters 
Optional functions starting within a local SH service are: 

• service_synchronization_f unction : 

the start flag of the service_synchronization_function MAY be used in a SHIP external to common SH service. 

• Other functions specific to the local transmitters belonging to the cell where the local service is present 
(transmitter_*). 

All those functions MUST be transmitted in the current SHIP. 

4.2.2.1.1.3.3 PSI/SI tables 

SI tables MUST be signalled according to repetition intervals. Their content is according to clause 4.2.2.1.2.2. 

4.2.2.1 .2 Filtering processing 

4.2.2.1 .2.1 General procedure 

The filtering at SH service layer consists in: 

• Selecting those SH services from the "complete TS" that need to be kept in the "localized TS", e.g. based on 
SHIP signalling (see [6], clause A.4.9) 

• Extracting the corresponding MPEG2 TS packets including MPE, MPE-EEC, MPE-IEEC, SHIP, PSI/SI, 
NULL. 

• Updating the MPE / MPE-IEEC headers real time parameters of the selected ES, in particular the delta-t: 

delta-t for the common services in the global and local "regionalized TS" being based on the repetition 
interval and global "regionalized TS" bitrate; 

delta-t for the local services in the local "regionalized TS" being based on the repetition interval and local 
"regionalized TS" bit rate; 

see clause 4.3 for more details. 
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• Creating or updating the SHIP packets inside the common and/or local SH service to signal the new 
synclironization_time_stamp value based on the actual "regionalized TS" (whether global or local) bit rate, and 
the new service arrangement in the synchronization function. 

NOTE: if there are different radio configurations not impacting the bit rate (such as different FFT sizes), the radio 
parameters of the SHIP need to be aligned in the corresponding areas. For instance in two different 
terrestrial celllDs, different FFT MAY be used resulting in different mandatory parameters. 

• Creating or updating the PSI such as the PAT and the PMT to reflect the list of local DVB services that are 
present on the local SH service only (see clauses 4.2.2.1.2.2 and 4.5). 

4.2.2.1.2.2 PSI/SI scope 

A DVB-SH receiver MUST consider the received SI as valid for all other "regionalized TS" of the same TS. 

On the contrary, a DVB-SH receiver MUST consider the PSI of the current "regionalized TS" as only valid for the 
current TS: 

• Even if all PMT of the complete TS services are present, the only PMT of the local (and common) DVB 
services actually present are valid, the other PMT being void. 

• As an exception, the PAT MAY be considered as valid for all "regionalized TS". 
A procedure is given to illustrate how PMT MUST be interpreted by the DVB-SH receiver: 

• The PMT MUST be monitored during an update period equal to a SH frame duration before being considered 
as updated. 

• During this update period, a DVB-SH terminal receiving a void PMT SHALL NOT conclude that the service 
is not present but that this DVB service is not globally available. 

• All received PMT during the update period MUST be considered. Only when the update period has ended that 
any conclusion can be drawn. 

• Therefore at the end of the update period the following events MAY occur for each DVB service signalled by 
a PMT: 

If a non-void PMT for the corresponding DVB service has been received, then the corresponding ES of 
the DVB service are actually conveyed in the regionalized TS. 

If only void PMT for the corresponding DVB service have been received, then no ES of the DVB service 
is actually present in the "regionalized TS". 

• The following situation CAN therefore occur: 

Those DVB-SH receivers receiving only the global "regionalized TS" will get: 

■ For common DVB services: complete PMT within the global SH service; 

■ For local DVB services: void PMT within the global SH service. 

NOTE 1: DVB-SH receivers will therefore have no information on the DVB services that are not present since all 
corresponding PMT are void. 

Those SH receivers receiving only the local "regionalized TS" will get: 

■ For common DVB services: complete PMT within the common SH service; 

■ for local DVB services: void PMT within the common SH service; 

■ for local DVB services: complete PMT within their corresponding local SH services. 

NOTE 2: DVB-SH receivers will consider the local ES as present based on existence of non-void PMT. 

PMT SHALL be updated when a change in the receiver situation occurs (change in regionalized TS reception 
conditions). 
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4.2.2.1 .3 "Regionalized TS" attributes 

4.2.2.1 .3.1 Common SH service attributes 

4.2.2.1.3.1.1 Data 

For the sake of code combining, all the bits of the common services MUST be identical in all regionalized TS. 

All adapters MUST keep the same number of MPEG2 TS packets from the common SH service. 

All adapters MAY modify MPEG2 TS packets provided that all adapters of the SH network perform the modification 
simultaneously and identically. 

MPE / MPE-FEC / MPE-IFEC section headers MUST be modified as follows: the delta-t must be updated to reflect 
change in bit rates and service distribution. 

4.2.2.1.3.2.1 Signalling 

Due to exact correspondence between common SH services in complete and regionalized TS, clause 4.2.2.1.1.2 apply. 
In addition, the following applies to the regionalized common SH services. 

• SHIP packets MUST be modified as to be valid for the global repeater: 

synchronization_time_stamp MUST be updated to reflect the new emission time of the next SH frame 
start due to the difference in bit rates between "complete TS" and global "regionalized TS"; 

SH service information MUST be modified to align with the service arrangement available on the global 
"regionalized TS"; 

Pointer MUST be kept unmodified so that this information is correct for the global modulator. 

As a consequence, the SHIP packets MAY not be valid for the local repeaters: 

■ STS and pointer MAY therefore not be correct for the local modulators and these modulators 
MUST ignore them. 

■ SH service information MAY not be correct after filtering on the local modulators when a SH 
service following the common one is removed. 

■ To signal that SHIP MUST be ignored by local modulators but not by global, its 
synchronization_id MUST be set to "1" (see clause 4.10.1.1 for more details). 

• PAT SHALL list all programs and therefore all DVB services of the "complete TS": 

PAT of the "regionalized TS" SHALL NOT be modified compared to "complete TS". See for more 
details clause 4.5.1. 

• All PMT present in the "complete TS" SHALL be present in common part of the "regionalized TS". 

All DVB services of the "complete TS" have their PMT present in the "regionalized TS". 

PMT describing local DVB services SHALL be void (no elementary streams are announced in the 
ES_info_loop, ES_info_length is set to '0') while keeping the same version_number. See for more details 
clause 4.5.2. 

• Other PSI/SI tables MUST be kept unmodified since they MUST be generic for all cells. 

4.2.2.1 .3.2 Local SH service attributes 

4.2.2.1.3.2.1 Data 

All modulators belonging to the cell where the SH service is modulated MUST keep the same number of MPEG2 TS 
packets from the local SH service (and discard those SH services that are not present in the cell). 
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Modulators MAY modify MPEG2 TS packets provided all modulators of the current cell perform this modification 
identically and simultaneously on a given region. 

NOTE : Two sub-regions MAY actually transmit same content but with different radio parameters not modifying 
the bit rate such as FFT. In such a case it is recommended to formally distinguish the two regions on the 
infrastructure side, each having its own set of radio parameters. 

MPE/MPE-FEC/MPE-IFEC section headers MUST be modified as follows: the delta-t must be updated to reflect the 
change in bit rates and service arrangement. See for more details clause 4.3. 

4.2.2.1.3.2.2 Signalling 

SHIP packets from the local SH service are relevant but MUST be updated as follows: 

• synchronization_time_stamp MUST be modified to reflect the emission time of the next SH frame due to the 
difference of bit rates between the "complete TS" and local "regionalized TS"; 

• service_synchronization function MUST be updated to signal the start of the common SH service in the next 
SH frame; 

• service_synchronization_function MAY list services present in the local TS. If this function does this listing, 
only the common and current local service(s) are listed in their sending order, all services being not 
transmitted in this local TS MUST not be listed (see clause 4.10.2.5); 

• pointer MUST not be updated; 

• synchronization_id MUST be set to '0' to indicate that this SHIP can be used for synchronization by the local 
modulator (see clause 4.10.1.1). 

NOTE 1 : SHIP packets in the common SH service are irrelevant for terrestrial repeaters (synchronization_id is set 
to T). 

PAT SHALL not be repeated and therefore SHALL be discarded if present in the local SH service. 

NOTE 2: PAT of the common SH service can be used by the receiver. 

PMT of common services and non-present local services are not repeated and MUST be discarded from the local SH 
service. Therefore only the PMT of the DVB services present in the local SH service SHALL be present. 

NOTE 3: PMT of the other DVB services (common and other local) can be found in the common SH service. 

Other PSI/SI tables MUST NOT be modified. 

4.2.2.2 Example (informative) 

Please refer to figure 10. 

At the global modulator, only the common DVB/SH service MUST be kept: 

• The time-slicing information MUST be always correct and MAY be used by the receiver for power saving 
purposes. 

• Only SHIP with synchronization_id set to T MUST be used: 

SH service 'next start' MUST be valid (signalling service T start); 

synchronization_time_stamp MUST be valid and can be used by the modulators for synchronization 
purpose; 

The SHIP pointer MUST be vaHd. 

• The PSI/SI MUST be vaHd. 



ETSI 



28 ETSI TS 1 02 470-2 V1 .1 .1 (2009-1 2) 

At a given local modulator, the common DVB-SH service MUST be kept along with one or several local DVB-SH 
services: 

• delta-t information signalled by MPE MUST be always correct (with some adjustment for the common 
services, see clause 4.3). 

• Only SHIP packets with synchronization_id set to '0' MUST be used: 

The SH service 'next start' MUST be vaHd. 

The synchronizaton_time_stamp MUST be valid. 

The pointer MUST be vaHd. 

• SHIP with synchronization_id set to T MUST be ignored; therefore there is only one valid SHIP per SH 
frame. 

• The PSI/SI are always correct. 

While receiving a global "regionalized TS" or a local "regionalized TS", the receiver will rely on the only delta-t 
signalled by the MPE headers to perform power saving (see clause 4.3 for more details). 

4.2.3 Filtering at TS layer 

TS layer filtering MAY or MAY not be performed using underlying SH service structure. Therefore only reference to 
DVB services SHALL be done in the following although SH services MAY also be used. 

4.2.3.1 Recommendations (normative) 

4.2.3.1 .1 "Complete TS" attributes 

BIT, RST, ST are ignored and SHOULD not be transmitted. 

4.2.3.1 .2 Filtering processing 

The filtering at TS layer consists in: 

• Selecting the TS packets belonging to the target DVB service(s). 

• Updating the MPE / MPE-IFEC headers real time parameters of the selected ES, in particular the delta-t. 

• Updating the SHIP packets to signal the new DVB-SH service sequence (if present) and the new 
synchronization_time_stamp/pointer values . 

• Updating the PAT and PMT tables to reflect the ES actual presence. 
To perform rate matching, NULL MPEG2 TS packets MAY be inserted. 

4.2.3.1 .3 "Regionalized TS" attributes / local SH service attribues 

MPEG2 TS packets carrying elementary streams belonging to filtered-out DVB services are discarded. 

MPEG2 TS packets carrying elementary streams belonging to filtered-in DVB services are kept. 

MPEG2 TS packets carrying elementary streams belonging to filtered-in DVB services MAY be modified provided this 
update is done identically and simultaneously on all modulators of the cell. 

MPE/MPE-FEC/MPE-IFEC sections headers are updated as follows: delta-t must be updated to reflect the change in bit 
rates and service arrangement. 
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SHIP is modified as follows: 

• service_synchronization function: service_index is updated to reflect new service arrangement (if present); 

• mandatory parameters: synchronization_time_stamp and pointer are updated to reflect the change in bit rates 
and service arrangement. 

One SHIP is inserted in each SH-frame whose capacity is computed from the actual modulation and encoding 
parameters. 

PMT are constituted as follows: 

• Only the PMT corresponding to the DVB services present in the "regionalized TS" SHALL be present. 

• The regionalized PMT SHALL list all elementary streams present in this DVB service. 
The PAT lists PMT that are present in the "regionalized TS" only. 

The INT MUST not be updated. 

The other PSI/SI tables are not modified. 

4.2.3.2 Example (informative) 

The examples are strictly the same as at the SH service layer with the following improvements: 

• the SHIP "next service" indication is always correct (if SH service is used), 
the PAT and PMT tables are not any more generic in the common part and no PMT SHALL be void. 



• 



4.3 Multiprotocol Encapsulation (normative) 

Clauses 4.3 and 5.2 of [8] apply without any exclusion. In addition, the following applies when paTS is used. 

4.3.1 SH SERVICE FILTERING 
4.3.1 .1 Common DVB-SH service 

In the common DVB service, if SH service filtering is used, the delta-t inserted in the real-time parameters is computed 
with a repetition interval equal to the actual common DVB service repetition interval and a bit rate equal to the bit rate 
used for global "regionalized TS" modulation. This computation is unique for all modulators, including the local ones. 
The DVB-SH receiver receiving the common DVB-SH service on the global "regionalized TS" MUST apply the 
signalled delta-t without any modification. 

When the global and local "regionalized TS" do not have same bit rates, assuming stretch_factor to be the ratio between 
local and global "regionalized TS" bitrates (stretch_factor>l), the DVB-SH receiver receiving the common DVB-SH 
service on the local frequency MUST update the signalled delta-t using one of the two following methods: 

• Assuming the receivers knows the position of the MPE section within the current SH frame as equal to 
t(start_current_framejQ^^j j3;current_sectjQ^^j j^), we can derive: 

A, the position of the MPE section within global TS: 
A=t(start_current_framejQ^^j j3 ;cur_sectjQ^^j j^) *stretch_factor. 

B, the position of the next burst within global TS: B=A+delta_t. 

C, the position of next burst within local TS: C=frame_duration*floor(B/frame_duration;0) + 
[B-frame_duration*floor(B/frame_duration;0)]/stretch_factor. 

D, the updated delta_t: D=C-A. 
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Assuming the receivers does not know the position of the MPE section within the current SH frame, the actual 
delta-t cannot be know precisely and we need substract the highest possible correction from the signalled 
delta-t value to avoid the receiver to wake up too late. This highest possible correction happens when the MPE 
section is at the beginning of the current SH frame (so both sections arrive at the same time on global and 
local) and the burst starts at the end of the target SH frame. In that case the delta-t is too long by 
SH_frame_duration*(l-l/strech_f actor). In the absence of MPE position knowledge within the SH frame, the 
delta-t needs then to be lowered by SH_frame_duration*(l-l/strech_factor): 



Af=At -ceil 



SH _ service _ duration '■ 



1-- 



1 



stretch _ factor 



^ -ilOms 



where and ceil(x)^Qj^g gives the highest and nearest duration expressed in units of 10 ms. 



4.3.1.2 



Local DVB-SH service 



The DVB-SH receiver receiving the local DVB-SH service on the local frequency MUST apply the signalled delta-t 
without any modification. 

In the following, we give one example that illustrates the need to update the delta-t on the "local regionalized TS". 
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Figure 12: Example of MPE delta-t updating 

The green delta-t signalled by first section of burst CI, 2 can be used as it is since the durations between, respectively, SH frame start and MPE section, and SH frame 
Start and next burst start, are identical. 

The red delta-t signalled by last section of burst CI, 2 need to be updated before being used in the "regionalized TS" since, in that case, the durations between SH frame 
Start and MPE section, and SH frame start and next burst start, are different. If not updated, the red delta-t would lead to a too-late wake up time. 
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4.3.2 TS LAYER FILTERING 

In TS layer filtering is used, the delta-t is computed on the actual "regionalized TS" with repetition interval being equal 
to the actual DVB service repetition interval and bit rate equal to the actual "regionalized TS" bit rate so that the 
DVB-SH receiver can process the delta-t signalling for all received services as usual. 



4.4 Descriptors (normative) 



The complete list of the descriptors, their use in different tables, and descriptor tags may be found in EN 300 468 [1] 
and EN 301 192 [2]. The list given in [8], clause 4.6 is fully applicable with the exceptions given hereunder. 

4.4.1 SH_delivery_system_descriptor 

SH_delivery_system descriptor can be found in [1]. 

The descriptor MUST be found in the NIT in the TS loop, where there is at most 1 descriptor for each TS. Its purpose is 
to precise, for a given TS, the main physical (modulation, code rate, interleaver. . .) parameters. In addition to the 
physical parameters, it also delivers basic information on diversity options, including MPE-IFEC if relevant. One 
should note that it lacks frequency information since the latter can be found in other descriptors inside the NIT. It differs 
significantly from previous terrestrial and satellite delivery system descriptors in the sense that it has been designed to 
accommodate a large variety of system configurations. Therefore its size varies depending on the chosen configuration. 

4.4.1.1 Diversity mode 

The descriptor starts with a diversity_mode that indicates principle diversity options selected for this TS: 

When paTS is not activated, there is no difference of content (in terms of hard bits) between the TS modulated on 
(possibly) different frequencies. The principle learning is that same bit rates are used for transmission on all frequencies 
listed in the cell_frequency_link_descriptror (see clause 4.4.5) and same 'hard bits' (including PSI/SI) are being 
modulated on all these cells. This does not however mean that there is no diversity supported: 



• 



In SEN configuration, diversity can be supported on the unique frequency at the receiver side at radio layer 
(e.g. using multiple radio combining). 

• In non-SEN configuration, diversity can be supported at physical layer with complementary code rates. To 
detect that complementary modes are used, the modulation loop has to be checked. 

When paTS is activated, this means that there is different content being transmitted over the different frequencies (in 
terms of hard bits), including PSI/SI that MAY differ between the different cells where the TS is being transmitted. 
Diversity_mode details how these different contents can be used for diversity purpose. 3 main combinations are 
possible: 

• "EEC at physical layer": this case corresponds to the combination of soft bits for specific SH services (the 
common one) using the "code combining" technique described in [7], clauses 7.2.2.3.3 and 7.4. In addition to 
the case where same code rates are being used (similar to the non-paTS non-SEN case described previously), it 
MAY be possible to use different complementary code rates. 

• "EEC at link layer": this case corresponds to the possibility to provide diversity at the link layer, using MPE 
and MPE-IEEC sections (this latter case is EES). In this case SH services MAY not be used, however SH 
usage even in this case is recommended in order to provide an homogeneous synchronization scheme. 

• Both previous cases together. 
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All different diversity options are presented in figure 13. 
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Figure 13: Diversity options 



4.4.1.2 



Modulation loop 



Then there is a loop on the modulation schemes. The number of iterations depends on the system configuration. In the 
simplest case, the SFN on one unique frequency, there is only one iteration describing an OFDM modulation. When 
additional diversity and/or frequencies are added, the number of iterations increases. Some examples are given in the 
table hereunder. 

Table 1: Examples of modulation iterations within SH_delivery_descriptor 



Case 


Description 


OFDM 
modulation 


TDM 
modulation 


1 


SH-A SFN with 1 satellite 


1 





2 


SH-A SFN with satellite diversity 


2 





3 


SH-B with 1 satellite and same terrestrial 
scheme 


1 


1 


4 


SH-B with 2 satellite and same terrestrial 
scheme 


1 


2 


5 


SH-B with 1 satellite and 
different terrestrial schemes 


As many 
terrestrial cells 


1 



Among all these case, the 5 needs special explanations given below through the modulation ordering loop design rules 
and their usage with the NIT context. 
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Since the frequency is not included in the SH_dehvery_system_descriptor, special care needs to be given to the 
modulation ordering according to the following rules: 

• Satellite modulations: 

Satellites modulation are always the first, terrestrial are the last. 

When several satellite modulations exist, they are all positioned at the beginning of the list. 

• Terrestrial modulations: 

When terrestrial modulations are the same on all frequencies, one unique iteration MUST be done. 

When different modulation parameters exist in the cells that transmit the TS, then all modulation 
schemes of all cells MUST be listed, even if some of them are redundant. 

• Transition between satellite and terrestrial modulations in the loop: 

When TDM is used for the satellite modulation, the transition is clearly defined by the change in the 
modulation scheme since TDM can only be used for a satellite transmission. 

When OFDM is used for the satellite modulation, there is an ambiguity in the transition since OFDM is 
also used for terrestrial modulation. Therefore the transition MUST be defined via another mechanism 
which is the common_frequency_flag: 

■ if OFDM modulation is used for satellite (SH-A mode), common_frequency flag SHALL be set to 
T for the relevant modulation scheme. 

■ if OFDM modulation is used for terrestrial (all cases), common_frequency flag SHALL be set 
to '0'. 

The usage of this ordering in conjunction with cell_frequency_link_descriptor is explained in the NIT section 
(clause 4.6.2). 

Each element in the loop has a size that depends on the actual individual physical parameters, essentially if TDM or 
OFDM modulation scheme is used, and if, and how the interleaver is configured. The design has been made the most 
compact possible when several modulation schemes are present, using the following rules: 

• When the interleaver is the same, it SHALL not be repeated after the first definition (interleaver_presence set 
to T for the first iteration, and '0' for the following). 

• More generally, when an interleaver_presence is set to '0', this means that the latest previously described 
interleaver MUST be used. This can be useful not only between the satellite and terrestrial modulation 
(previous case) but also between terrestrial modulations when different parameters other than the modulation 
are changed. 

• When the interleaver is of class 1, the short form SHOULD be used instead of the long form reserved for 
class 2. 

4.4.1 .3 Usage restrictions 

Some combinations MAY correspond to non-canonical SH configurations: for instance it is possible to configure a 
SH_delivery_system_descriptor with a unique TDM modulation. Due to this independence of the TDM configuration 
with regards to the OFDM, some care MUST be taken when OFDM and TDM are configured in the same descriptor: 
OFDM and TDM parameters MUST be harmonized according to SH specifications given in [6], in particular the 
symbol rate. 

When code combining is used in non-SFN conditions, then several modulations are present in the loop (at least 2) and 
complementary code rates MUST be announced. For instance in SH-B configuration with complementary codes, the 
following SH_delivery_system is used (see table 2). 
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Table 2: SH_delivery_system descriptor in SH-B with complementary code 



9/ntax 


Not bits 


elements 


Multi 




SH_d el i very_system_d exr i pto r (){ 

descriptor tag 

descriptor_extension_tag 

descriptorjength 

diversity_mode 

reserved 

tdm_modulation_dexriptor 

interleaver_dexriptor_complete 

ofdm_modulation_dexriptor 

interleaver dexriptorjDartial 

} 


8 
8 
8 
4 
4 

24 
32 
24 
8 



1 
2 


8 
8 
8 
4 
4 

24 


24 
16 




total in bits 
Total in bytes 
signaled in bytes 






96 
12 
10 


bits 
bytes 
bytes 



D VB- SHJd m_d escr i pto r 




m od u 1 ati n_d escr i pto rjype 


1 


interleaver_dexriptor_flag 


1 


interleaverjype 


1 


reserved 


5 


polarization 


2 


roll off 


2 


modulationjype 


2 


code_rate 


4 


symboLrate 


6 




24 



DVB-SH_ofdm_dexriptor 




modulation_dexriptor_type 


1 


interleaver_dexriptor_flag 


1 


interleaverjype 


1 


reserved 


5 


bandwidth 


3 


priority 


1 


constellation_and_hierarchy 


3 


code rate 


4 


guardjnterval 


2 


transmission_mode 


2 


satellitejrequency 


1 


24 



set to "0" 
set to "1 " 
set to "0" 



set to '1 000 CR= 1 /2 standard 



set to "1 " 
set to "1 " 
set to "1 " 



set to '1001 CR= 1/2 complementar 



4.4.2 time_slice_fec_identifier_descriptor 

This descriptor identifies whether time-shcing and/or MPE-FEC and/or MPE-IFEC are used on an elementary stream. 
This descriptor is used to announce each time-shced Elementary Stream. The descriptor is defined in [2], clause 9.5. 

When located in the first descriptor loop of NIT, the descriptor applies to all Elementary Streams within all Transport 
Streams within the DVB network. If located in the second descriptor loop of NIT, the descriptor applies to all 
Elementary Streams within the referred Transport Stream, overriding any time-slicing or EEC information from the first 
descriptor loop. 

If located in the platform descriptor loop of an INT, the descriptor applies to all Elementary Streams referenced within 
the table, overriding any time-slicing or EEC information from the NIT. If located in the target descriptor loop, the 
descriptor applies to all Elementary Streams referenced within the current iteration of the target descriptor loop 
following the appearance of the descriptor, overriding any time-slicing or EEC information from the platform descriptor 
loop and in the NIT. 

Note that the descriptor applies to Elementary Streams with stream_type 0x90. Other stream_type values may be 
specified later. 
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The descriptor may appear more than once, in which case each new occurrence overrides previous occurrence(s). 



4.4.3 Service Availability Descriptor 



This clause specifies the construction rules of the service_availability_descriptor, for the actual or a neighbouring 

partially available Transport Stream. We assume 1 TS having at least 1 SH_delivery system_descriptor with a paTS in 

at least 1 network: 

• Step 1 : the NIT sub_tables in scope SHALL be all the NIT sub_tables announcing this Transport Streams on 
networks where the SH_delivery_system_descriptor signals a paTS. 

• Step 2: the total set of cells in scope SHALL be all the cell entries of cell_frequency_link_descriptors assigned 
to this TS in the NIT sub_tables in scope. 

• Step 3: in the SDT sub_table of the Transport Stream, for each service entry of the services_loop: 

Step 3.1: within the total set of cells, identify the subset of filtering cells (i.e. the cells on which the 
service is not available). 

Step 3.2: in case two cell entries or more share the same cell_id, while providing opposite availability 
information for the service (whether the cell descriptions of these cell entries are identical or not), the 
common cell_id value SHALL be added to the subset of filtering cells. 

Step 3.3: if the subset of filtering cells is empty, continue to next service entry. 

Step 3.4: otherwise, include the service_availability_descriptor, as follows: 

either set availability_flag to 0, and list in the descriptor the cell_id(s) of the subset of filtering 
cells; 

or set availability_flag to 1 , and list in the descriptor the cell_id(s) of the total set of cells that are 
not present in the subset of filtering cells. 

NOTE: Value of availability_flag could change for each inclusion of the service_availability_descriptor, in order 
for instance to produce the shortest list of cell_id(s) as possible in the descriptor. 

4.4.4 cell_list_descriptor 

4.4.4.0 Introduction 

This descriptor lists all the cells of the DVB network together with their cell_id. 

4.4.4.1 General requirements 

The descriptor appears in the first descriptor loop of a NIT sub_table describing an IPDC DVB-SH Network and the 
cell hst MUST be complete. 

The following applies: 

• Due to the definition regarding the sign of latitudes and longitudes the south-western corner of the rectangle is 
specified. 

• In case of large list of cells exceeding the capacity of the cell_list_descriptor (a maximum of 25 cells can be 
listed in a cell_list_descriptor) and/or the capacity of the NIT sub-table section (of a maximum size of 

1 024 bytes), the descriptor MAY appear several times inside the NIT table. 

• The splitting rules as defined in [i. 1 ] , clause 4.1.11.2 apply in that case. 
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4.4.4.2 Special case of satellite cells 

Cells corresponding to a satellite transmission are called beams. 

Their celljd is taken in the range [0;255] so that AND(cell_id;OxFFOO) = 0x0000. 

The descriptor also lists the locations and the extension of the listed cells. While the location of a satellite cell does not 
bring any complexity, the extension of an overflow current maximum values: 

• cell_extent_of_latitude is coded on 12 bits but with steps of 90 / 2^^; maximum value is therefore 1 1,25°. 
While cell_extent_of_latitude maximum values MAY be suitable for a pan-European satellite (±11°), these 
values fall short for a North American coverage (+12°). 

• cell_extent_of_longitude is coded on 12 bits but with steps of 180 / 2^^; maximum value is therefore 22,5°. 
While cell_extent_of_longitude maximum value MAY be suitable for a pan-European satellite (±20°), value 
for beam covering North America (±30°) or Middle East (±50°) are much more demanding. 

In order to signal values beyond the maximum, it is recommended to use the value '0'. Extension '0' therefore means that 
cell is of extension greater than the maximum allowable value. 

4.4.4.3 Special case of terrestrial cells 

Cells corresponding to a terrestrial transmission MUST have a cell_id of value greater than 255. Therefore AND 
(cell_id;OxFFOO) must differ from 0x0000. 

4.4.5 cell_frequency_link_descriptor 

4.4.5.1 General requirements 

This descriptor lists all the frequencies used in transmission of a multiplex within the DVB network. It gives a complete 
list of cells and identifies the frequencies that are in use in these cells for the multiplex described. 

The following applies: 

• It can appears more than once in each iteration for which there is a SH_delivery_system_descriptor when the 
list of cells exceed the capacity of the descriptor (a maximum of 36 links can be listed in a 
cell_frequency_list_descriptor) and/or the capacity of the NIT sub-table section (of a maximum size of 

1 024 bytes), or when there are different groups of cells to be attached to different modulation schemes 
(see clause 4.6.2.1.5). 

• The splitting rules as defined in [i. 1], clause 4. 1 . 1 1 .2 apply in that case. 

• The list of frequencies is complete. 

4.4.5.2 Special case of frequency diversity: 

When diversity of frequency is used in non-SFN configurations, the following ordering rules apply: 

• Satellite cells are listed first, terrestrial cells are listed last. 

4.5 PSI tables (normative) 

4.5.1 Program Association Table (PAT) 

4.5.1 .1 Introduction (informative) 

Program Association Table (PAT) provides the correspondence between a program_number and the PID value of the 
Transport Stream packets that carry the DVB service definition. The program_number is the numeric label associated 
with a DVB service. The overall table is contained in one or more sections. It may be segmented to occupy multiple 
sections. 
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A DVB network transmits the PAT on every Transport Stream. The PAT contains no descriptors. The program loop 
within PAT contains information about each DVB service within the actual Transport Stream: 

If the program_number 0x0000 is announced, the corresponding network_PID field is set to 0x10. 

The program_number of each DVB service available within the Transport Stream is announced. The 
corresponding program_map_PID indicates the PID of the PMT sub_table for the DVB service. A PMT 
sub_table is carried within an Elementary Stream with PID value between 0x0020 ... OxlFFE. 

The PAT table does not contain multiple iterations of the program loop with the same value of the 
program_number field (i.e. each program_number is announced only once). 

4.5.1 .2 Requirements (normative) 

The following requirements apply to all cases: 

• PAT is always delivered in the Elementary Stream with the PID 0x0000. 

• For bit rate optimisation reasons, all Elementary Streams used to carry IP streams of a particular IP platform 
SHOULD be carried by a single DVB service unless paTS is used. 

• DVB-SH Network SHALL transmit PAT on each Transport Stream of the DVB network. The repetition 
period of all PAT sections is RECOMMENDED to be SH_frame_duration ms or lower. 

• If a DVB-SH Receiver is receiving an IP stream, the following applies: 

Receiver SHALL detect changes in the PAT table (version number field). 

In connection with receiving a burst. Receiver SHALL check for a new version of the PAT during on- 
time of the time-sliced Elementary Stream. Receiver MAY ignore PAT filtering during the off -period of 
the time-sliced Elementary Stream. 

The following requirements apply to cases where the TS is of paTS nature at SH service layer: 

• The PAT SHALL list all DVB services. This applies to the common DVB service but also to all local DVB 
services, including those that are not present in the cell. 

• The PAT SHALL be present in the common SH service and SHALL not be present in the local SH services. 

• A PAT table section shall not span two successive SH services. One PAT table section SHALL end before the 
end of the current SH service. 

The following requirements apply to cases where the TS is of paTS nature at TS layer 

• The PAT SHALL list only those DVB services that are actually being sent on the paTS, keeping program_map 
PIDs that have been filtered-in, removing those that have been filtered out. The filtered-in program_numbers 
as well as the program_map_PID SHALL not be modified. 

4.5.2 Program Map Table (PMT) 
4.5.1 .1 Introduction (informative) 

The Program Map Table (PMT) provides mappings between program numbers and the program elements that comprise 
them. A PMT sub_table announces the mapping for a single DVB service. Within a Transport Stream, a PMT sub_table 
is identified by the program_number. A PMT sub_table is also referred to as a "program definition". The PMT is the 
complete collection of all program definitions (i.e. all PMT sub_tables) for a Transport Stream. 

The program_number of each DVB program should be unique within the network. The PMT sub_table for a particular 
DVB service is transmitted on the same Transport Stream as the referred DVB service, except for the partially available 
case where (void) PMT sub tables referring local DVB services MAY be found in the global regionalized TS. 
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Descriptors in the PMT important for use in IPDC DVB-SH Systems are: 

data_broadcast_id_descriptor: For each component containing INT sub_table(s), this descriptor with 
data_broadcast_id set to OxOOOB (IP/MAC Notification Info Structure) is located in the ES_info loop. Each 
INT sub_table within the Elementary Stream is announced. 

stream_identifier_descriptor: for each component carrying IP streams, this descriptor is located in the ES_info 
loop. The component_tag announced within the descriptor is unique for each component within the DVB 
service. 

4.5.1 .2 Requirements (normative) 

The following requirements apply to all cases. 

• Generic requirements 

DVB-SH Receiver SHALL support usage of multiple PMT sub_tables on a Transport Stream for a single 
IP platform. 

DVB-SH Network SHALL transmit all PMT sub-tables on each Transport Stream of the DVB network. 

The repetition period of all PMT sections is RECOMMENDED to be SH_frame_duration or lower. 

A PMT sub-table SHALL be carried by a unique section of maximum size 1 024 bytes, including header 
and CRC, where the section_number field is set to 0. 

Each PMT sub_table is delivered in an Elementary Stream on the PID announced in the PAT. Different 
PMT sub_tables may be delivered on different Elementary Streams, in which case they are differentiated 
by the PID. However different PMT sub-tables MAY be delivered on the same Elementary Stream, in 
which case sub-tables are differentiated by the program_number. 

The PCR_PID field MAY be set to OxlFFF, indicating that no PCR is associated with the program. 

DVB-SH Receiver MAY ignore PCR even if available. 

• The following descriptor types are important in DVB-SH System and may appear in a PMT sub_table: 

stream_identifier_descriptor; 
data_broadcast_id_descriptor. 

• DVB-SH Receiver MAY ignore all other descriptors, when present. 

• DVB-SH Receiver SHOULD follow changes in PMT sub_table while accessing components of the DVB 
service. Id est while receiving an INT sub_table or an IP stream carried within the components of a DVB 
service, a Receiver SHOULD also filter for newer versions of the PMT sub_table of that DVB service. 

The following requirements apply to AA^ services: 

• These requirements apply for components carrying IP stream. 

• For each component carrying IP stream(s), the stream_type SHALL be set to value of 0x90. 

• The ES_info_loop associated with an Elementary Stream carrying IP stream(s) SHALL contain a 
stream_identifier_descriptor announcing the component_tag of the Elementary Stream. This component_tag 
SHALL be unique within the DVB service. The announced component_tag SHALL have the same value as in 
the corresponding data_broadcast_descriptor in the SDT (if any). 
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• If a DVB-SH Receiver is receiving an IP stream, the following applies: 

The Receiver SHALL detect changes in an INT sub_table within the same Transport Stream announcing 
the received IP stream by detecting changes in PMT sub_table announcing the Elementary Stream where 
INT sub_table is carried. 

In connection with receiving a burst, Receiver SHALL check for a new version of the corresponding 
PMT sub_table during on-time of the time-sliced Elementary Stream. Receiver MAY ignore filtering of 
the particular PMT sub_table during the off-period of the time-sliced Elementary Stream. 

The following requirements apply to notification services: 

• These requirements apply for components carrying INT sub-tables. 

• In case there is only one IP platform, component(s) carrying INT sub_table(s) SHOULD be announced as the 
first component(s) within the PMT sub_table of the DVB service. In case of several IP platforms, all 
components ) carrying INT sub_table(s) MAY be found in the same PMT sub_table. 

• For each component carrying INT sub_table(s), the stream_type SHOULD be set to value of 0x05. 

• Each INT sub_table within an Elementary Stream SHALL be announced using a data_broadcast_id_descriptor 
in the corresponding PMT sub_table. The descriptor SHALL be located in ES_info_loop associated with the 
component. The descriptor SHALL appear exactly once for each INT sub_table carried within the Elementary 
Stream. In the data_broadcast_id_descriptor, the data_broadcast_id SHALL be set to value of OxOOOB, 
indicating that the descriptor contains IP/MAC Notification Info Structure (see clause 4.9). 

The following requirements apply to cases where the TS is of paTS nature at SH service layer: 

• During global "regionalized TS" transmission of the common SH services, all PMT of the "complete TS" are 
repeated. Those PMT listing local DVB services MUST be void (ES_info_length set to '0'). 

• During local "regionalized TS" transmission of the local SH services, only those PMT of the "complete TS" 
listing DVB services that are present MUST be present and MUST NOT be void. In case several local SH 
services are present, each PMT MUST be located in the SH service carrying the DVB service signalled by this 
PMT. 

• The PMT sub-tables corresponding to the different DVB local services SHOULD be transmitted on the same 
Elementray Stream with the same PID. Section packing SHALL be used to lower transmission overhead, 
especially when a high number of local services is present. 

• A PMT sub-table section SHALL not span two successive SH services: one PMT sub-table section SHALL 
end before the end of the current SH service. 

The following requirements apply to cases where the TS is of paTS nature at TS layer: 

• During global "regionalized TS" transmission, only the PMT of the common DVB services are transmitted. 
Those PMT listing local DVB services MUST not be present. 

• During local "regionalized TS" transmission, only the PMT of the common and those local DVB services 
actually present are transmitted. Those PMT listing local DVB services not present MUST not be transmitted. 

4.5.3 Conditional Access Table (CAT) 

Same content as [8], clauses 5.4.3 and 4.4.3. 

4.5.4 Transport Stream Description Table (TSDT) 

Same content as [8], clauses 5.4.4 and 4.4.4. 
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4.6 SI Tables (normative) 

4.6.1 Bit rates and repetition intervals 



4.6.1.1 



SH modes excluding diversity at SH service level 



In all SH modes excluding diversity at SH service level, the following applies to all SI tables transmitted over the TS 
exiting the IP encapsulator: 

The time between transmitting sequential sections of a sub_table SHOULD NOT exceed 100 ms, and the time 
between the last byte of the preceding section and the first byte of the next section SHALL not be less than 
25 ms. 

The bandwidth used by an Elementary Stream transmitting sections of any sub_table SHOULD NOT exceed 
1 Mbps calculated over any period of half a second. 

TS 102 470-1 [8] illustrates the requirements for times between sections of a sub_table. The maximum time of 100 ms 
is between sequential sections of a sub_table. The minimum time of 25 ms is between the last section of a sub_table to 
the first section of the next occurrence of the sub_table. The maximum repetition rate of a table defines the maximum 
time within which all sections of every sub_table of the table shall be transmitted once. 

Note that different sub_tables of a particular table may be transmitted simultaneously. 
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Figure 14: Times between sections of sub_tables (general case) 

4.6.1 .2 SH modes supporting diversity at SH service level 

In modes supporting diversity at SH service level, these rules at the output of the IP encapsulator are modified as 
follows: 

In the common DVB service, the preceding rules MUST be respected with the corresponding global 
"regionalized TS" bit rate and during the common service duration. 

In the local DVB services, the rules MUST be respected for each service with the corresponding local 
"regionalized TS" bitrate and during the local service duration. 

The stretch factor being defined as the ratio between the local and the global "regionalized TS" bitrates 
(stretch_factor>l), due to the repetition of the common service on the local network: 

The repetition intervals within the common service will be higher and the 25 ms time between two 
succeeding sections of the same sub table must not be lower than stretch_factor*25. 

The bandwidth used by an Elementary Stream transmitting sections of any sub_table calculated over any 
period of half a second will be higher. 
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Figure 15: Times between sections of sub_tables (code diversity case) 
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Therefore the rules are the following in case diversity at SH service level is used: 

The time between transmitting sequential sections of a sub_table SHOULD NOT exceed 100 ms as computed 
with a bit rate equal to the global "regionalized TS" one for the common service and the local "regionalized 
TS" one for the local service. 

In the common service, the time between the last byte of the preceding section and the first byte of the next 
section SHALL not be less than 25 ms multiplied by the stretch_factor and as computed with a bit rate equal to 
the global "regionalized TS" one. 

In the local service, the time between the last byte of the preceding section and the first byte of the next section 
SHALL not be less than 25 ms as computed with a bit rate equal to the local one. 

In the common service, the bandwidth used by an Elementary Stream transmitting sections of any sub_table 
SHOULD NOT exceed 1 Mbps / stretch_f actor calculated over any period of half a second with the global bit 
rate. 

In the local service, the bandwidth used by an Elementary Stream transmitting sections of any sub_table 
SHOULD NOT exceed 1 Mbps calculated over any period of half a second and with the local "regionalized 
TS" bit rate. 

4.6.2 Network Information Table (NIT) 
4.6.2.1 NIT_actual 

4.6.2.1 .1 Introduction (informative) 

In general clause 4.5.1 of [8] applies unless contradicted by the requirements below. 

4.6.2.1.2 Generalities 

A DVB-SH Network SHALL transmit the NIT_actual on each Transport Stream of the DVB network. The NIT_actual 
SHALL contain exactly one SH_delivery_system_descriptor for each of Transport Streams of the actual delivery 
system and provide valid information about the Transport Stream. 

A cell MAY contain multiple Transport Streams where IP streams are carried over DVB-SH sent on different 
frequencies. When hierarchical modulation is used, there MAY be up to two TS sent in the same frequency AND cell. 

The following descriptors are important in DVB-SH System and SHALL appear in a NIT_actual sub_table: 

network_name_descriptor; 

linkage_descriptor with a linkage type of OxOB or OxOC; 

SH_delivery_system_descriptor; 

cell_list_descriptor; 

cell_frequency_link_descriptor. 

The following descriptor MAY appear in a NIT_actual sub_table: 

• time_slice_fec_identifier_descriptor. 

DVB-SH Receiver MAY ignore other descriptors, when present. 

DVB-SH Receiver MAY assume the content of NIT_actual being static (i.e. not changing) during the time it is attached 
to a DVB network. Therefore a receiver may read the content of NIT_actual only when it attaches to the DVB network. 
A DVB-SH Receiver SHOULD read the content of NIT_actual every time it is attaching a DVB network (either when 
powered on, or when changing from a DVB network to another). The NIT does not depend on the location of the 
receiver and is the same under satellite and terrestrial coverage. 
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Due to the potentially large size of a NIT, it MAY be possible that the NIT exceeds the admissible size of a sub-table. In 
that case, the segmentation rules found in [i.l], clause 4.1.11.2 apply. 

4.6.2.1 .3 Linkage descriptors 

The following applies to each Transport Stream carrying one or more INT sub_tables: 

• The NIT_actual SHALL contain at least one linkage_descriptor with a linkage_type of OxOB or OxOC. 

• If the NIT_actual carries linkage_descriptor(s) with a linkage_type of OxOB, the following applies: 

The descriptor(s) SHALL announce each DVB service carrying INT sub_table(s) within the actual DVB 
network. 

Each of the descriptor(s) SHALL carry exactly one IP/MAC Notification Service Structure announcing 
one or more IP/MAC Notification Services. 

The list of IP/MAC Notification Services announced SHALL be complete. The list is complete if all INT 
sub_tables within the DVB network are referred to by at least one linkage_descriptor with a linkage_type 
of OxOB. 

The following applies to each Transport Stream not carrying any IP flows: 

The Transport Stream SHOULD carry a linkage_descriptor with a linkage_type of OxOC within its NIT_actual, 
announcing at least one NIT_actual within the DVB network containing a linkage_descriptor with a linkage_type of 
OxOB. 

4.6.2.1 .4 Network name_descriptors 

The following applies to the network_name_descriptor: 

The descriptor SHALL appear exactly once in the first descriptor loop. The descriptor SHOULD contain the name of 
the DVB network (i.e. SHOULD NOT contain an empty string). 

4.6.2.1 .5 SH_delivery_system_descriptor, cell_list_descriptor, 
cell_frequency_link_descriptor 

The following applies to the SH_delivery_system_descriptor: 

• The descriptor SHALL appear at most once in each iteration of the transport_stream_loop (i.e. for each 
announced Transport Stream). Traditionally the descriptor is assumed to appear once in each iteration. 
However when several iterations make use of exactly the same descriptor, it can be omitted in replacement of 
the latest previously listed. 

• There is no frequency given in the SH_delivery_system_descriptor, these are signalled by the 
cell_frequency_link_descriptor. 

The following applies to the cell_list_descriptor: 

• The descriptor SHALL be present in the first descriptor loop. 

• The descriptor MAY appear more than once within the descriptor loop. 

• Descriptor syntax MUST follow rules defined in clause 4.4.4, in particular: 

The cell and subcell list SHALL be complete. 
Cell_id range depends on cell type (satellite, terrestrial). 
The following applies to the cell_frequency_link_descriptor: 

• This descriptor SHALL appear in the transport_stream_loop to list all the frequencies where the Transport 
Stream is available within the DVB network. 



ETSI 



45 ETSI TS 1 02 470-2 V1 .1 .1 (2009-1 2) 

• Descriptor syntax SHALL follow rules defined in clause 4.4.5, in particular: 

The list of announced frequencies SHALL be complete. 

Cell list order depends on cell type (satellite, terrestrial). 

The way SH_delivery_system_descriptor, cell_list_descriptor and cell_frequency_link_descriptor and combined is the 
following: 

• Inside the main loop, the cell_list_descriptor describes all cells present in the network, their cell_id and 
latitude/longitude extension MUST follow the specific syntax given in clause 4.4.4. 

• For each TS in the TS loop, one SH_delivery_system_descriptor is given that follows the syntax of 
clause 4.4.1 and gives as many modulation loop as needed. 

• For each TS in the TS loop, one (logical-wise since actually several descriptors MAY be used depending on 
the size of the list and the topology of the groups) cell_frequency_link_descriptor follows that specifies on 
which cells and what frequencies the TS is being repeated. The cells are grouped in two categories depending 
on their cell_id, the satellite and the terrestrial. 

• Cells belonging to different categories (satellite and terrestrial) MAY be found in the same descriptor provided 
that the order (satellite first, terrestrial second) is respected, but this is not mandatory. A different descriptor 
MAY be used to list the terrestrial cells. 

• Inside each category, the following rules apply individually: 

If there are as many cell entries in the cell_frequency_link_descriptor as there are modulation entries in 
the SH_delivery_system_descriptor, then the modulation entries are one to one allocated to the different 
cells: first modulation entry to first cell, second modulation entry to second cell, etc. 

If there are more than one entry in the cell_frequency_link_descriptor but only one modulation entry in 
the SH_delivery_system_descriptor, then this unique modulation entry MUST be allocated to all cells 
listed in the cell_frequency_link_descriptor. 

EXAMPLE: We assume in table 3 a SH-B system where a unique TS is being distributed over a unique satellite 
cell and 10 local cells. 
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Table 3: Example of SH-B NIT (1 TS, 1 satellite cell, 10 terrestrial cells) 



Syntax 


N of bits 


elements 


Multi 


network_information_section(){ 








tablejd 


8 




8 


section_syntax_indicator 


1 




1 


reserved_for_future_use 


1 




1 


reserved 


2 




2 


sectionjength 


12 




12 


networkjd 


16 




16 


reserved 


2 




2 


version_n umber 


5 




5 


current_next_indicator 


1 




1 


section_n umber 


8 




8 


last_section_n umber 


8 




8 


reserved_for_future_use 


4 




4 


network_descriptor_length 


12 




12 


network_name_dexriptor 


96 




96 


cell_list_dexriptor 


816 




816 


linkage_dexriptor 


72 




72 


reserved_for_future_use 


4 




4 


transport_slream_loop_length 


12 




12 


transport_stream_id 


16 




16 


original_network_id 


16 




16 


reserved_for_future_use 


4 




4 


transport_dexriptors_length 


12 




12 


SH_system_delivery_dexriptor 


96 




96 


cell_frequency_link_dexriptor 


552 




552 


CR332 
} 


32 


1 


32 



satellite TS loop 



cell_list_dexriptor 






descriptorjag 




8 


descriptorjength 




8 


All cells 




792 


celljd 


16 




celljatitude 


16 




celljongitude 


16 




cell extent of latitude 


12 




cell_extent_of_longitude 


12 




subcelljnfojoopjength 




8 
816 



1 sat + 10 ter cells 



unitary size 
72 bytes 



cell_frequency_link_descriptor 
descriptorjag 
dexriptorjength 
All cells 




8 

8 

528 


celljd 


16 




frequency 
subcelljnfojoopjength 


32 


8 
552 



1 sat + 10 ter cells 
"I unitary size 
1 48 bytes 



ETSI 



47 ETSI TS 1 02 470-2 V1 .1 .1 (2009-1 2) 

NOTE 1: It can be seen that the number of hsted satelhte and terrestrial cells in the cell_list_descriptor is 1 and 10 
respectively. In the TS loop, there is only one TS being listed, the satellite one. The 
SH_delivery_system_descriptor has 2 entries, 1 for TDM and 1 for OFDM whereas the 
cell_frequency_link_descriptor lists 1 1 entries, the first being the satellite cell (cell_id < 256) and the 
others being terrestrial cells (cell_id > 255). Therefore the unique satellite cell is related to the unique 
satellite TDM modulation entry whereas the terrestrial cells are all related to the also unique OFDM 
modulation entry. 

If there are larger entries in the cell_frequency_link_descriptor than in the 
SH_delivery_system_descriptor and there are several modulation entries, then each modulation 
entry MUST be allocated to a distinct group of cells according to the following rules: 

Each modulation entry corresponds to a group of cells. Therefore there are as many groups of 
cells as there are modulation entries. 

Cells (and their corresponding frequencies) belonging to a group of cell (and for which a 
specific modulation entry apply) are listed by a cell_frequency_link_descriptor or a set of 
consecutive cell_frequency_link_descriptors when the size of one descriptor reaches the 
capacity of an individual descriptor and/or the capacity of an individual NIT sub-table. In the 
latter cases plitting rules described in [i.l], clause 4.1.11.2 apply. 

When the list of {cells; frequencies} belonging to this group is complete and a new group has 
to be listed, a void cell_frequency_link_descriptor MUST be inserted between the two groups 
to delineate the separation between two consecutive groups and avoid ambiguity about which 
modulation entry MUST be used. 

EXAMPLE: We assume in table 4 a SH-A system where a unique TS is being distributed over a unique satellite 
cell and two groups made of 10 cells each. The two groups have different modulation parameters 
differing only by the used EFT. 
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Table 4: Example of SH-B with two groups of terrestrial cells having different FFT 



Syntax 


N of bits 


elements 


Multi 


network information section(){ 








table id 


8 




8 


section ^ntax indicator 


1 




1 


reserved for future use 


1 




1 


reserved 


2 




2 


section length 


12 




12 


network id 


16 




16 


reserved 


2 




2 


version number 


5 




5 


current next indicator 


1 




1 


section number 


8 




8 


last section number 


8 




8 


reserved for future use 


4 




4 


network_descriptor_length 


12 




12 


network name descriptor 


96 




96 


celljistjdescriptor part 1 


16 








celljistjdescriptor part 2 


896 




896 


linkage descriptor 


72 


2 


144 


reserved for future use 


4 




4 


tra nsport_strea mjoopjength 


12 




12 


transport_stream_id 


16 




16 


original network id 


16 




16 


reserved for future use 


4 




4 


transport descriptors length 


12 




12 


SH_system_d el i veryjd escr i pto r 


120 




120^ 


cell frequency link descriptor 


680 




.680 


CFC32 
} 


32 




r- 



^ntax 


Not bits 


elements 


SH delivery system descriptor(){ 






descriptorjag 


8 




descriptor_extension_tag 


8 




descriptor length 


8 




diversity mode 


4 




reserved 


4 




tdm modulation descriptor 


24 


1 ^ 


interleaver descriptor complete 


32 





ofdm modulation_descriptor 


24 


2 '^ 


interleaverjdescriptorjDartial 

} 


8 


2 



1 TDM modulation 



-2 OFDM modulation (FFT 1 a FFT 2) 



72+2*296+16=680 



1 X: 
2X: 

1 X: 








TDM links 

, — OFDM links 

. Transition between 2 OFDM groups 


cellJrequencyJink_descriptor_satellite 

descriptorjag 

descriptorjength 

All_cells 

celljd 

frequency 

subcelljnfojoopjength 


16 
32 
8 


8 
8 
56 


72 








celljrequencyjinkjdescriptorjerrestrial 

descriptorjag 

descriptorjength 

AILcells 

celljd 

frequency 

subcelljnfojoopjength 


16 
32 
8 


8 
8 
280 


296 








celljrequencyjinkjdescriptorjerrestrial 

descriptorjag 

descriptorjength 

AILcells 

celljd 

frequency 

subcelljnfojoopjength 


16 
32 
8 


8 
8 


16 









NOTE 2: It can be seen that the number of hsted satelhte and terrestrial cells in the cell_list_descriptor is 1 and 10 
respectively. In the TS loop, there is only one TS being listed, the satellite one. The 
SH_delivery_system_descriptor has 3 entries, 1 for TDM and 2 for OFDM (one with FFT 1, the other 
with FFT 2) whereas the cell_frequency_link_descriptor lists 11 entries in 3 separate descriptors: the first 
descriptor list the unique satellite cell and frequency (cell_id < 256), the second list the 5 cells and 
frequencies using the first OFDM modulation and the last list the 5 cells and frequencies related to the 
second OFDM modulation. 

NOTE 3: It would have been possible to list the satellite and the fist 5 cells of the first group in the same 

cell_frequency_link_descriptor since their cell_id can identify them unambiguously. For clarity purpose 
we have separated them in 2 descriptors in the example given. 

4.6.2.1 .6 time_slice_fec_identifier_descriptor 

The following applies to the time_slice_fec_identifier_descriptor: 

• When located in the first descriptor loop, the descriptor applies to all elementary streams with stream_type 
0x90 within all transport streams announced within the sub-table. 

• When located in the second descriptor loop, the descriptor applies to all elementary streams with stream_type 
0x90 within the specific transport stream. This descriptor overwrites any descriptors in the first descriptor 
loop. 
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4.6.2.2 NIT_other 

4.6.2.2.1 Specific requirements 

A DVB-SH Network MAY transmit NIT_other on one or more Transport Streams of the DVB network. NIT_other has 
to be vahd and only announce an existing network. In case other network is dehvered using SH modulation, NIT_other 
SHALL contain exactly one SH_delivery_system_descriptor for each of the Transport Streams of the actual delivery 
system and provide valid information about the Transport Stream. Otherwise, NIT_other follows specification of [8], 
clause 5.5.1.2 

4.6.2.2.2 Generic requirements 

Other requirements applicable for NIT_actual are also application for NIT_other. 

4.6.3 Bouquet Association Table (BAT) 

Same as [8], clauses 5.5.2 and 4.5.2. 

4.6.4 Service Description Table (SDT) 

4.6.4.1 Introduction 

In DVB-SH networks with paTS, different types of SDT tables can be used, contrarily to DVB-H networks where only 
SDT_actual are used: 

SDT_actual (table_id = 0x42) describes the services present in actual TS. 

SDT_other (table_id = 0x46) describes the services present in other TS, be they in the current or other 
networks. 

The two types of table are defined in [1], clause 5.2.3. 

4.6.4.2 SDT_actual 

A DVB-SH Network SHALL transmit SDT_actual sub_table (tablejd 0x42) for the actual Transport Stream. All 
transmitted sections of the SDT_actual for the actual multiplex SHALL be transmitted at least every 2 s. 

The services_loop of the SDT_actual sub-table SHALL contain information about all DVB services composing the 
Transport Stream (id-est before filtering when this is a paTS). Each DVB service SHOULD NOT be announced more 
than once within an SDT_actual sub_table. 

In a DVB-SH System, the following descriptor types SHALL appear in the SDT_actual of a Transport Stream where 
one or more MPE section streams are available: 

service_descriptor; 

data_broadcast_descriptor. 

In a DVB-SH System, the following descriptor types MAY appear in the SDT-actual of a Transport Stream where one 
or more MPE section streams are available: 

service_availability_descriptor. 

DVB-SH Receiver MAY ignore other descriptors, when present. 

The following applies to the SDT_actual when announcing a DVB service carrying INT sub_table or IP streams: 

• The EIT_schedule_flag SHOULD be set to value of 0x00, indicating that the EIT schedule information for the 
DVB service is not present in the Transport Stream. DVB-SH Receiver MAY ignore schedule information if 
present. 

• DVB-SH Receiver MAY ignore present/following information if present. 
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• The running_status SHOULD be set to value of 0x04, indicating that the DVB service is currently running. 

• The following applies to the service_descriptor: 

The descriptor SHALL be present. 

DVB-SH Receiver SHALL NOT assume any particular value for the service_type. 

The service_provider_name MAY contain the service provider name. DVB-SH Receiver MAY ignore 
service provider name. 

The service_name MAY contain the DVB service name. DVB-SH Receiver MAY ignore service name. 

• The following applies to the data_broadcast_descriptor: 

The descriptor SHALL be present for each component carrying one or more MPE section streams within 
the DVB service. 

It MAY occur more than once. DVB-SH Receiver MAY ignore them all but one, for which the following 
applies: 

The data_broadcast_id field SHALL be set to value 0x0005. 

The component_tag field SHALL be set to the value of the component announced within the PMT 
sub_table of the DVB service. 

The descriptor SHALL contain Multiprotocol Encapsulation Info Structure. For the structure, the 
following applies: 

MAC_address_range SHALL be set to value of 0x01, indicating that only MAC_address_6 
in the header of MPE sections carried within the referred component contains valid 
MAC-address information; 

MAC_IP_mapping_flag SHOULD be set to T, indicating that it uses the IP to MAC 
mapping as described in RFC 1 1 12 [3] for IPv4 multicast addresses, and RFC 2464 [4] for 
IPv6 multicast addresses; 

alignment_indicator SHALL be set to '0', indicating that alignment of 8 bits is used; 

max_sections_per_datagram SHALL be set to value of 0x01, indicating that each IP 
datagram is carried in exactly one MPE section. 

DVB-SH Receiver MAY ignore the text description of the data component, if present. 

• The following applies to the service_availability_descriptor: 

The inclusion as well as the generation of this descriptor SHALL follow clause 5.3.3 of the present 
document. 

Note that a DVB-SH Receiver does not use MAC address for filtering MPE section streams. 

A DVB-SH Receiver SHALL NOT ignore SDT_actual, when it describes a paTS as signalled by 

SH_delivery_system_descriptor, as it may signal some restrictions on the service availability of the described Transport 
Stream. 

4.6.4.3 SDT_other 

A DVB-SH Network SHALL transmit SDT_other sub_table (table_id 0x46) for each non-actual Transport Stream 
fulfilling the three following conditions: 

The Transport Stream is a paTS as announced by SH_delivery_system_descriptor diversity _mode. 

The Transport Stream is a neighbouring Transport Stream, i.e. transmitted in geographically co-located, 
adjacent or intersecting cells, whether belonging to the actual and/or other network(s). 

The Transport Stream is actually filtered in one of the neighbouring cells. 
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All transmitted sections of the SDT_other for the actual multiplex SHALL be transmitted at least every 10 s. 

Remaining requirements are similar to SDT_actual and recalled for memory. 

The services_loop of the SDT_other sub-table SHALL contain information about all DVB services composing the 
Transport Stream (id-est before filtering when this is a paTS). Each DVB service SHOULD NOT be announced more 
than once within an SDT_other sub_table. 

In a DVB-SH System, the following descriptor types SHALL appear in the SDT_other of a Transport Stream where one 
or more MPE section streams are available: 

service_descriptor; 

data_broadcast_descriptor. 

In a DVB-SH System, the following descriptor types MAY appear in the SDT_other of a Transport Stream where one 
or more MPE section streams are available: 

service_availability _descriptor. 

DVB-SH Receiver MAY ignore other descriptors, when present. 

The following applies to the SDT_other when announcing a DVB service carrying INT sub_table or IP streams: 

• The EIT_schedule_flag SHOULD be set to value of 0x00, indicating that the EIT schedule information for the 
DVB service is not present in the Transport Stream. DVB-SH Receiver MAY ignore schedule information if 
present. 

• DVB-SH Receiver MAY ignore present/following information if present. 

• The running_status SHOULD be set to value of 0x04, indicating that the DVB service is currently running. 

• The following applies to the service_descriptor: 

The descriptor SHALL be present. 

DVB-SH Receiver SHALL NOT assume any particular value for the service_type. 

The service_provider_name MAY contain the service provider name. DVB-SH Receiver MAY ignore 
service provider name. 

The service_name MAY contain the DVB service name. DVB-SH Receiver MAY ignore service name. 

• The following applies to the data_broadcast_descriptor: 

The descriptor SHALL be present for each component carrying one or more MPE section streams within 
the DVB service. 

It MAY occur more than once. DVB-SH Receiver MAY ignore them all but one, for which the following 
applies: 

The data_broadcast_id field SHALL be set to value 0x0005. 

The component_tag field SHALL be set to the value of the component announced within the PMT 
sub table of the DVB service of the other TS. 
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The descriptor SHALL contain Multiprotocol Encapsulation Info Structure. For the structure, the 
following applies: 

MAC_address_range SHALL be set to value of 0x01, indicating that only MAC_address_6 
in the header of MPE sections carried within the referred component contains valid 
MAC-address information; 

MAC_IP_mapping_flag SHOULD be set to T, indicating that it uses the IP to MAC 
mapping as described in RFC 1112 [3] for IPv4 multicast addresses, and RFC 2464 [4] for 
IPv6 multicast addresses; 

alignment_indicator SHALL be set to '0', indicating that alignment of 8 bits is used; 

max_sections_per_datagram SHALL be set to value of 0x01, indicating that each IP 
datagram is carried in exactly one MPE section. 

DVB-SH Receiver MAY ignore the text description of the data component, if present. 

The following applies to the service_availability_descriptor: 

The inclusion as well as the generation of this descriptor SHALL follow clause 5.3.3 of the present document. 

Note that a DVB-SH Receiver does not use MAC address for filtering MPE section streams. 

A DVB-SH Receiver SHALL NOT ignore SDT_other, when it describes a paTS as signalled by 

SH_delivery_system_descriptor, as it may signal some restrictions on the service availability of the described Transport 
Stream. 

4.6.4.4 Determining service availability 

4.6.4.4.1 Service availability of the actual TS on the current cell 

This clause specifies how an IPDC DVB-SH Receiver can determine the service availability of the actual Transport 
Stream on the current cell. 

In this procedure, the following prerequisites are known to the IPDC DVB-SH Receiver: 

Identity of the actual Transport Stream (original_network_id, transport_stream_id). 

If one service only is of interest, identity of the service (service_id). 

Identity of the current cell (cell_id). 

The IPDC DVB-SH Receiver SHOULD conclude to the availability of all the services of the actual Transport Stream 
on the current cell: 

if the delivery_system_descriptor given for the Transport Stream implicitly or explicitly declares to not 
support or apply service filtering; or else 

if the SDT_actual sub_table is (unexpectedly) not found. 

Otherwise, the IPDC DVB-SH Receiver SHOULD determine the availability of [one specific service I each service] of 
the actual transport Stream as follows: for [the service entry I for each service entry] in the services_loop of SDT_actual 
sub_table, the service is available on current cell: 

if the service_availability_descriptor is absent; or else 

if the availability_flag is unset and actual cell_id is not listed in the descriptor; or else 

if the availability_f[ag is set and actual cell_id is listed in the descriptor; 

otherwise the service is not available on the current cell. 
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4.6.4.4.2 Service availability of a TS on the cells of a given network 

This clause specifies how an IPDC DVB-SH Receiver can determine the service availabihty of a Transport Stream in a 
given network. More specifically the purpose of this procedure is to determine, within the cells listed by the 
cell_frequency_link_descriptor given for the Transport Stream in this network, on which cell(s) each service is actually 
available. 

In this procedure, the following prerequisites are known to the IPDC DVB-SH Receiver: 

Identity of the Transport Stream (original_network_id, transport_stream_id). 

If one service only is of interest, identity of the service (service_id). 

Identity of the network (network_id). 

The IPDC DVB-SH Receiver performs the following initialization steps (should one of these steps fails, the procedure 
is aborted): 

If not already done, retrieve the NIT sub_table identified by network_id. 

If not already done, check the presence of the Transport Stream in the TS loop of the NIT sub_table. 

Retrieve the cell_frequency_link_descriptor as well as the delivery_system_descriptor given for the Transport 
Stream in the TS loop iteration. 

The IPDC DVB-SH Receiver SHOULD conclude to the availability of all the services of the Transport Stream on all 
the cells listed by the cell_frequency_link_descriptor: 

if the delivery_system_descriptor implicitly or explicitly declares to not support or apply service filtering, or 
else; 

if the SDT (actual or other) sub_table associated to this Transport Stream is not found. 

Otherwise, the IPDC DVB-SH Receiver SHOULD determine the availability of [one specific service I each service] of 
the actual transport Stream as follows: for [the service entry I for each service entry] in the services_loop of SDT 
sub_table : 

if the service_availability_descriptor is absent, the service is available on all the cells listed by the 
cell_frequency_link_descriptor, or else; 

if the availability_flag is unset, the service is only available on the cells of the cell_frequency_link_descriptor 
which are not listed in the service_availability_descriptor, or else; 

if the availability_flag is set, the service is only available on the cells listed by the 
cell_frequency_link_descriptor which are besides listed in the service_availability_descriptor. 

4.6.5 Event Information Table (EIT) 

Same as clauses 5.5.4 and 4.5.4 in [8]. 

4.6.6 Running Status Table (RST) 

Same as clauses 5.5.5 and 4.5.5 in [8]. 

4.6.7 Time and Date Table (TDT) 

Same as clauses 5.5.6 and 4.5.6 in [8]. 

4.6.8 Time Offset Table (TOT) 

Same as clauses 5.5.7 and 4.5.7 in [8]. 
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4.6.9 Stuffing Table (ST) 

Same as clauses 5.5.8 and 4.5.8 in [8]. 

4.6.10 IP/MAC Notification Table (INT) 

This clause gives precisions on the way INT MUST be used in a DVB-SH context. It is divided into two parts: the first 
is valid for all SH configurations whereas the second specific to cases when the TS is partially available. 

4.6.1 0.1 CoiTinnon specifications 

4.6.10.1.0 Introduction 

This clause is applicable to all SH configurations. 

4.6.10.1.1 Generalities 

An IP platform MAY have IP streams on multiple Transport Streams within a DVB network. An IP platform MAY 
have IP streams on multiple DVB networks. 

Two Transport Streams carrying IP streams of a particular IP platform MAY carry the same, partially different, or 
entirely different set of IP flows of the IP platform. 

Two IP flows carried on a single Elementary Stream on a particular Transport Stream MAY be carried on different 
Elementary Streams on another Transport Streams as well. 

If one or more IP streams of an IP platform are carried within a Transport Stream, the Transport Stream SHALL carry 
the INT sub_table describing the IP platform. 

An IP stream MAY be announced on INT sub_tables of two or more IP platforms (i.e. one IP stream MAY belong to 
multiple IP platforms). 

The INT sub_table of a particular IP platform SHALL NOT be carried in multiple Elementary Streams (i.e. only one 
copy allowed) on a particular Transport Stream. 

DVB-SH network MAY use IPv4 and/or IPv6. Within one IP platform, and therefore INT, only one IP version 
SHOULD be used. 

The INT is referenced by a data_broadcast_id_descriptor with a data broadcast id of OxOOOB, in the ES_info loop of the 
PMT (see clause 4.9 for more information on ways to signal the INT). 

An INT table may consist of one or more INT sub_tables. INT sub_tables are differentiated by platform_id and 
action_type: 

The platform_id is used to identify the IP platform. Within the actual transport stream, a DVB-SH Network 
SHALL transmit one INT sub_table for each IP platform delivering IP streams within the Transport Stream. It 
is generally recommended to use one IP platform per service provider. 

The action_type indicates the action to be performed. Currently the only action type supported is 0x01, which 
means that location of IP streams in DVB networks is announced. The processing_order field of an INT 
sub_table with action_type 0x01 SHALL be set to value of OxFF or 0x00, indicating that no ordering is 
implied. 

All transmitted sections of the INT SHALL be transmitted at least once in every 30 s. 

The INT is structured in two loops inside which different descriptors are used: 

the platform_descriptor_loop; 

the target and operational descriptor loops. 
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INT sub_table SHALL announce each IP stream of the IP platform available on the actual Transport Stream 
(i.e. target-loop SHALL contain a descriptor announcing the IP address of the corresponding IP flow, and the 
corresponding operational-loop SHALL contain a descriptor announcing the location of the IP stream within the actual 
Transport Stream). 

INT sub_table SHOULD announce each IP stream of the IP platform available on the neighbouring Transport Streams. 
Neighbouring Transport Streams are Transport Streams, which are transmitted in geographically co-located, adjacent or 
intersecting cells. In the specific case of a satellite cell (called a beam, cell_id < 255) the cell is neighbour of all 
terrestrial cells within the coverage of the satellite cell. Although the number of IP streams MAY be quite large, in 
particular if there are local TS transmitted in the terrestrial cells, a different platform_id for signalling IP streams 
available only on the local TS SHALL be avoided. 

4.6.1 0.1 .2 Platform_descriptor_loop 

The following descriptors MAY appear in platform_descriptor_loop: 

IP/MAC_platform_name_descriptor: Platform_loop MAY contain this descriptor, containing the name of the 
IP platform in one or more languages. The descriptor MAY occur more than once. Each occurrence of the 
platform_name SHOULD be identical with the platform_name announced using the same language code in 
NIT containing IP/MAC Notification Service Structure. 

time_slice_fec_identifier_descriptor: If this descriptor is present in platform_loop, it indicates that all 
Elementary Streams referred within this INT sub_table are time-sliced with parameters announced in this 
descriptor. 

DVB-SH Receiver MAY ignore all other descriptors in platform-loop. 

4.6.1 0.1 .3 Target_descriptor_loop 

Following descriptors MAY appear in target-loop: 

target_IP_address_descriptor; 

target_IP_slash_descriptor; 

target_IP_source_slash_descriptor; 

target_IPv6_address_descriptor; 

target_IPv6_slash_descriptor; 

target_IPv6_source_slash_descriptor. 
Each iteration of 2^^ loop of INT table SHALL contain at least one of the above listed target-descriptors in target-loop. 

Descriptor_length field of any descriptor in this loop SHALL NOT be set to "0" (i.e. the descriptor SHALL signal at 
least one IP flow). 

An IP flow SHALL NOT be announced in more than one iteration of 2^^ loop of INT table. 

IP streams carried within an Elementary Stream SHALL use the same version of IP protocol. I.e. mixing IPv4 and IPv6 
datagrams within a single Elementary Stream is not allowed. 

Following applies to each target_IP_address_descriptor within the 2^^ loop of INT table: 

The use of target_IP_slash_descriptor or target_IP_source_slash_descriptor instead is RECOMMENDED. 

Note that this descriptor can contain maximum of 62 IPv4_addr fields. 

IPv4_addr_mask field indicates the bits significant in each IP address announced in the following IPv4_addr 
fields within the descriptor. 

This descriptor refers to every IP flow with any source address and any of the announced destination address. 
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Following applies to each target_IP_slash_descriptor within the 2^^ loop of INT table: 

Note that this descriptor can contain maximum of 5 1 IPv4_addr fields. 

IPv4_slash_mask indicates the number of significant bits in the corresponding IPv4_addr, starting from the 
msb. 

This descriptor refers to every IP flow with any source address and any of the announced destination address. 

Following applies to each target_IP_source_slash_descriptor within the 2^^ loop of INT table: 

Note that this descriptor can contain maximum of 25 IPv4_addr fields. 

IPv4_source_slash_mask indicates the number of significant bits in the corresponding IPv4_source_addr, 
starting from the msb. 

IPv4_dest_slash_mask indicates the number of significant bits in the corresponding IPv4_dest_addr, starting 
from the msb. 

This descriptor refers to every IP flow with any of the announced source address and any of the announced 
destination address. 

Following applies to each target_IPv6_address_descriptor within the 2^^ loop of INT table: 

The use of target_IPv6_slash_descriptor or target_IPv6_source_slash_descriptor instead is 
RECOMMENDED. 

Note that this descriptor can contain maximum of 14 IPv6_addr fields. 

IPv6_addr_mask field indicates the bits significant in each IPv6 address announced in the following IPv6_addr 
fields within the descriptor. IPv6_addr_mask value ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffOO would indicate that the 8 
Isb of the IPv6_addr value are to be ignored. 

This descriptor refers to every IP flow with any source address and any of the announced destination address. 

Following applies to each target_IPv6_slash_descriptor within the 2^^ loop of INT table: 

Note that this descriptor can contain maximum of 15 IPv6_addr fields. 

IPv6_slash_mask indicates the number of significant bits in the corresponding IPv6_addr, starting from the 
msb. IPv6_slash_mask_value 120 would indicate that the 8 Isb of the IPv6_addr value are to be ignored. 

This descriptor refers to every IP flow with any source address and any of the announced destination address. 

Following applies to each target_IPv6_source_slash_descriptor within the 2^^ loop of INT table: 

Note that this descriptor can contain maximum of seven (7) IPv6_addr fields. 

IPv6_source_slash_mask indicates the number of significant bits in the corresponding IPv6_source_addr, 
starting from the msb. 

IPv6_dest_slash_mask indicates the number of significant bits in the corresponding IPv6_dest_addr, starting 
from the msb. 

This descriptor refers to every IP flow with any of the announced source address and any of the announced 
destination address. 

If the IP/MAC_stream_location_descriptors associated with the first descriptor announce different locations 
than the IP/MAC_stream_location_descriptors associated with the second descriptor (i.e. located in different 
iteration of 2^^ loop of INT table), DVB-SH Receiver would need to know which of the locations to use. For 
such cases, following applies: 

If within an INT sub_table an IP flow is announced multiple times using different masks. Receiver 
SHALL use the one with more precise mask (i.e. the mask with more bits set). If several announcements 
are available it is to the implementation to decide which one to use, not to a DVB standard to specify 
this. 
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4.6.1 0.1 .4 Operational_descriptor_loop: 



NOTE: This clause is identical to clause 5.5.9 of [8] dealing with operational_descriptor_loop and recalled for 
consistency. 

Following descriptors MAY appear in operational-loop: 

IP/MAC_stream_location_descriptor: Each iteration of 2^^ loop of INT table SHALL contain at least one 
IP/MAC_stream_location_descriptor in operational-loop, providing the location of IP streams. Given location 
SHALL NOT occur more than once within each iteration of 2^^ loop of INT table. 

time_slice_fec_identifier_descriptor: If this descriptor is present in target_loop, it indicates that all Elementary 
Streams referred within this loop after this descriptor are time-sliced with parameters announced in this 
descriptor. Descriptor applies from the next IP/MAC_stream_location_descriptor (if any) to the end of the 
current iteration of the loop or to the next time_slice_fec_identifier_descriptor, which ever comes first. 

The IP/MAC_stream_location_descriptor SHOULD have different content within each iteration of 2^^ loop of INT 
table (i.e. SHOULD announce different location). 

DVB-SH Receiver MAY ignore all other descriptors in operational-loop. 

4.6.1 0.2 Specificities in the case of a partially available TS 

4.6.1 0.2.1 Unicity and availability of the INT 

Each sub-table SHALL be part of the common services in case the TS is partially available so that the complete INT is 
available anywhere in the DVB-SH network. There MAY be a number of IP streams that are not available on the 
common service but only on the local service. Therefore the number of IP streams to be announced in the INT sent in 
the common service MAY be quite large. However due to the 30 seconds repetition interval, the bit rate increase is 
expected to remain limited. 

4.6.1 0.2.2 Multiplicity of IP/MAC_stream_location_descriptors within operationaljoop: 

With a partially available TS, it MAY be possible that multiple IP/MACstream_location_descriptor entries exist for 
same target_IP_descriptor, whereby the same IP flow MAY be instantiated by different IP streams found in different 
DVB services. In such case, appearance order of the different IP/MAC_stream_location_descriptors within the 
operationaljoop is of importance and MUST follow the rules : 

if the IP flow is present in a common DVB service, the position of the corresponding 
IP/MAC_stream_location_descriptor SHALL be first; 

if the IP flow is present on several local DVB services. 
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The procedure for the receiver to choose the correct IP stream and corresponding DVB service is the following: 

1) the terminal should: 

scan the INT table and the operational_loop; 

select an IP address ; 

find a matching {target_descriptor_loop(); operational_descriptor_loop() } in the loop following the 
platform_descriptor_loop ; 

in the operational_descriptor_loop() more than one IP/MACstream_location_descriptor will be found for 
the actual TS; 

the first IP/MACstream_location_descriptor of the list should be the one associated with the satellite 
DVB service, other being associated to the local DVB services. 

2) According to this order, a procedure can be followed as described under: 

Step 1: list all services that contain the target IP address; 

Step 2: check availability of the service in the SDT table, the latter being cached in the memory; 

Step 3: if only one service is available, use its service_id to trigger the IP flow; 

Step 4: if two services are available, use the service_id that is not in the first position of the list to trigger 
the IP flow. 

4.7 Transmission Parameters Signalling (TPS) 

The Transmission Parameters Signalling (TPS) bits are used to signal parameters related to the OFDM transmission 
scheme, i.e. to channel coding, modulation and interleaver. They are specified in [6], clause 5.7.4.3. 

The Signalling Field is used to signal parameters related to the TDM transmission scheme, id est interleaver and 
channel coding (the modulation is supposed to have been resolved beforehand). The signalling field is specified in [6], 
clause 5.5.2.2. 

4.8 Update Notification Table (normative) 

Same as clauses 5.7 and 4.10 in [8]. 



4.9 Announcing INT (normative) 



This clause summarizes how the INT SHALL be announced. The description starts from the ES that carries the INT and 
follows signalling backwards. 

4.9.1 IP/MAC Notification Service 

An elementary stream that carries an INT is called IP/MAC Notification service. This Elementary Stream is then called 
a IP/MAC Notification Service. An IP/MAC Notification Service MAY carry multiple INT sub_tables. An IP/MAC 
Notification Service SHOULD NOT carry any other data but INT sub_tables. DVB-SH Receiver MAY ignore any 
other data on an Elementary Stream carrying one or more INT sub_tables. 

The notification service MUST be announced in the PMT describing the elementary stream where the INT is carried. 
The IP/MAC Notification Info Structure announces each INT sub_table carried within the announced component (see 
clause 4.9.2 for more details). 

The DVB service described by this PMT is itself announced by an IP/MAC Notification Service Structure. The latter is 
located within a linkage_descriptor that MAY be found in the NIT_actual of each Transport Stream containing one or 
more IP/MAC Notification Services (see clause 4.9.3 for more details), or in BAT carried on at least one of the 
Transport Streams of the network (see clause 4.9.4 for more details). 
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4.9.2 IP/MAC Notification Info structure 

As defined in clause 8.3.1 of [2], the structure is located in the ES_info loop of the PMT, precisely in the selector field 
of data_broadcast_id_descriptor, with the data_broadcast_id field set to OxOOOB. There is exactly one structure per 
data_broadcast_id_descriptor but there MAY be several data_broadcast_id_descriptors within the ES_loop. 

Following applies to each IP/MAC Notification Info Structure found in the PMT: 

At least one INT sub_table SHALL be announced. 

More than one INT sub_tables SHOULD NOT be announced. 

If more than one INT sub_tables are announced within a single structure, each SHALL have a different 
platform_id. 

If more than one platform_id are present, the list of platform_ids shall be complete. 

For each announced platform_id, action_type 0x01 (location of IP/MAC streams in DVB networks) SHOULD 
be announced exactly once. 

INT_versioning_flag fields SHALL be set to T, indicating that the INT_version field reflects the changes of 
the announced INT sub_table. 

NOTE: If INT_versioning_flag is set to 1, a Receiver needs to filter only the PMT sub_table to detect changes in 
PMT and INT sub_tables. If the flag is set to 0, the Receiver needs to filter both PMT and INT sub_table, 
therefore requiring one extra filter. 

4.9.3 IP/IVIAC Notification NIT 

As defined in [1], the IP/MAC Notification Service Structure is carried within exactly one linkage_descriptor, located in 
the first descriptor loop of a NIT. There is exactly one structure per linkage_descriptor but there MAY be several 
linkage_descriptors in the NIT main loop. 

The following applies to each NIT containing IP/MAC Notification Service Structure: 

• Each notification service within the DVB-SH network is announced in the NIT. 



• 



• 



• 



If there are several IP platforms and therefore several INT sub_tables, these are announced in the same 
IP/MAC Notification Service Structure. 

In that case, the list of announced IP platforms SHALL be complete, so that each INT sub_table within the 
entire DVB network is referred to by at least one linkage_descriptor containing an IP/MAC Notification 
Service Structure. 

A platform_name SHALL be given for each announced IP platform. The platform_name MAY be announced 
just once within each NIT containing IP/MAC Notification Service Structures. 



To get the names of each available IP platform within a DVB network, a DVB-SH Receiver would read the NIT 
containing linkage_descriptors with linkage_type OxOB. Within such NIT, names of each available IP platform are 
announced. 

4.9.4 IP/IVIAC Notification BAT 

If an IP/MAC Notification BAT is used, the following applies: 

The BAT sub_table should be announced within the NIT sub_tables describing the actual delivery system. 

To announce a BAT sub_table, a NIT carries a linkage_descriptor with the linkage_type set to OxOC. 

As defined in [1], the IP/MAC Notification Service Structure is carried within exactly one linkage_descriptor, located in 
the first descriptor loop of a specifically identified BAT sub_table. There is exactly one structure per linkage_descriptor 
but there MAY be several linkage_descriptors in the BAT main loop. 
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Each IP/MAC Notification BAT announces each IP/MAC Notification Service within the DVB network. For each such 
DVB service, each IP platform for which INT sub_tables are carried in components of the service, is announced. 

The following applies to each BAT containing IP/MAC Notification Service Structure: 

Each IP/MAC Notification Service within the DVB network is announced in the BAT. 

If there are several IP platforms and therefore several INT sub_tables, these are announced in the same 
IP/MAC notification service structure. 

In that case, the list of announced IP platforms SHALL be complete, so that each INT sub_table within the 
entire DVB network is referred to by at least one linkage_descriptor containing an IP/MAC Notification 
Service Structure. 

A platform_name SHALL be given for each announced IP platform. The platform_name MAY be announced 
just once within each BAT containing IP/MAC Notification Service Structures. 

To get the names of each available IP platform within a DVB network, a DVB-SH Receiver would read the BAT 
containing linkage_descriptors with linkage_type OxOB. Within such BAT, names of each available IP platform are 
announced. 

4.1 SH frame initialization packet (normative) 

SHIP is defined in [6], annex A. Its usage is refined in this clause. 

4.10.1 Mandatory SHIP parameters 

Mandatory parameters are set according to specified rules except for the following parameters: 

• synchronization_id; 

• individual_addressing_length. 

4.10.1.1 Synchronizationjd: 

When SH_delivery_system_descriptor signals a diversity_mode where FEC diversity is used at SH service layer 
(diversity_mode XNOR '1110' = '1111'), the synchronization_id can be set to two different values: 

• SHIP located in common services MUST have their synchronization_id set to 0x01; 

• SHIP located in local services MUST have their synchronization_id set to 0x00. 

Therefore, transmitters located in terrestrial cells (cell_id > 255) MUST behave as usual, synchronizing on SHIP with a 
synchronization_id set to 0x00, and avoid using SHIP with a synchronization_id set to 0x01 that are reserved to 
transmitters located in satellite cell. Transmitters located in satellite cells (cell_id < 256) MUST use the unique SHIP 
with a synchronization_id set to 0x01. 

4.1 0.1 .2 lndividual_addressing_length 

In unicast configuration ('OxOO'<individual_addressing_length<'OxFF') individual_addressing_length informs how many 
tx_identifiers entries there are in the SHIP so that multiple tx_identifiers can be addressed within the same SHIP. Using 
multicast addressing can be more efficient to address a large number of transmitters and therefore makes 
individual_addressing_length useless. Multicast and unicast addressing are therefore exclusive. When multicast 
addressing is used (individual_addressing_length = OxFF), this field can no more be used for setting the number of 
multicast entries. However, the receiver can still derive the number of entries from the section length and the individual 
function_loop_length. It is then still recommended to use several tx_identifier entries per SHIP even in the multicast 
case. 

Using service_synchronization function assumes a multicast tx_identifier addressing scheme is used (length set to 
'OxFF'). 
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Using service_localization function assumes a unicast tx_identifier addressing scheme is used (length set strictly 
between to '0x00' and 'OxFF'). 

4.10.2 Optional SHIP parameters 

In this clause, we precise how some of the optional functions useful in a DVB-SH context SHALL be used: after some 
general requirements, we review cell_id function, service_localization function and service_synchronization function. 
Other optional SH-related (TDM, group_membership) or non SH-related functions MAY be used in a SH context but 
do not require specific guidance. 

4.10.2.1 General requirements 

According to clause 4.1.2.1, in the specific case of diversity used at SH service layer (diversity_mode XNOR '1110' = 
'1111'), the SHIP packet SHALL signal the optional parameters in the common service so that any receiver will receive 
this information. 

If the optional function cannot be transmitted in a unique SHIP because of size, then the information SHALL be split 
into successive SHIP packets because the payload of a SHIP (184 bytes) is not enough for carrying the optional data. 
This happens in the following cases: 

• The list of tx_identifiers cannot be completed within the current SHIP: at least one tx_identifier address has 
been described but more are requested. 

• An optional function cannot be ended within current SHIP: there is not enough bytes left in the current payload 
to complete the function, especially if this function has many iterations: 

For service_localization_f unction: with a unique multicast address for all cells, we can signal localization 
of 17 cells with 1 service declared in each cell within 1 SHIP. 

For service_synchronization_function: With a unique multicast address an no cell_id, we can signal a 
total number of services of 77. 

To detect the multiple SHIP situation, the terminal cannot use section_length since the latter is limited to 182 bytes, 
therefore preventing this parameter to be used in multiple SHIP context. Wait_for_enable_flag is used for that purpose: 
the terminal discovers that there is a multi-SHIP case because the wait_for_enable_flag is set to '0' on the intermediate 
SHIP and set to T on the final SHIP where an enable_function MUST be located. So the terminal has to monitor 
successive SHIP to discover the full configuration. Moreover, in all cases, at each iteration, the individual_addressing 
length signals the length within current SHIP so that total length is the sum of all successive signalled lengths. 

More precisely, the syntax rules are the following: 

• A function MAY be split into several parts called hereunder "the parts". 

• Each part MUST be correctly signalled and compliant with the SHIP specification: 

For a given part, function description MUST be complete: fields function_tag, function_length, data, 
wait_for_enable_flag, reserved MUST be present and correctly set. 

For a given part, function_loop_length MUST be set to the length of the part of the function located 
within current SHIP. 

Wait_for_enable_flag MUST be set to T up to the reception of enable_function with the corresponding 
enable_f unction_tag . 

Function MUST be enabled with reception of the function last part, or the following one if no room is 
available on the last part. 
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The complete function CAN be built from individual parts to constitute a compliant function: 

The complete function description MUST be complete: fields function_tag, function_length, data, 
wait_for_enable_flag, reserved MUST be present. 

The complete function_loop_length MUST be set to the sum of lengths of all individual parts and 
MUST be limited to 255 bytes. 

Wait_for_enable_flage MUST be set to T up to the reception of enable_function with the 
corresponding enable_function_tag. 

Additional following rules are mandated: 

If signalling for a given tx_identifier MUST be split over several SHIP, the same tx_identifier SHOULD be 
used in all successive SHIP (the signalling MUST not change the addressing before completing the current 
one). This applies to both unicast and multicast addressing schemes. 

This rule MAY not be respected with content regionalization cases where different SHIP are generated for the 
global and local regionalized TS. However this rule MUST be respected for the sequence of individual SH 
service present and valid in the same cell. 

The SHIP sequence SHALL be repeated regularly so that any transmitter or receiver performing a cold start 
SHALL be able to retrieve the complete sequence within a small delay and so that a missed intermediate SHIP 
MAY be recovered quickly. 

4.10.2.2 Txjdentifier 

Tx_identifier syntax depends on individual_addressing_length. See the later for more information. 

4.10.2.3 Celljdjunction 

This cell_id SHALL be present when service_localization function is used to give binding information between cell_id 
and SH service (refer to service_localization_function for more information on this binding). 

4.10.2.4 Service_localization_f unction: 

4.10.2.4.0 Introduction 

This service_localization_function enables to discover what SH services are actually on which region. This function is 
therefore useful for both transmitters and receivers since both need to discover the SH regionalization information. 

The service_localization_function by itself only lists the SH services. In order to provide binding information between 
the region and the SH services, the tx_identifiers and the cell_ids need to be detailed according to the following rules. 

4.10.2.4.1 txjdentifier 

For providing binding information between the service_localization_function and the transmitters, the following rules 
on tx_identifier are recommended: 

• For signalling a common SH service alone: an individual tx_identifier (individual_addressing_length strictly 
between 0x00 and OxFF) MUST be used unless the TS is being modulated over several satellite modulators. 

• For signalling a local SH service: a multicast addressing scheme (individual_addressing_scheme equal to 
OxFF) SHOULD be used since in the general case several modulators are located in a terrestrial cell; multicast 
addressing is therefore convenient for informing all the transmitters at once. 

• For signalling a common SH service among other local services: a multicast addressing scheme 
(individual_addressing_scheme equal to OxFF) SHOULD be used in order to address in the same SHIP the 
different transmitters. 
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4.10.2.4.2 



Cell id 



For providing binding information between the service_localization_f unction and the receivers, the cell_id function 
MUST be used in the same SHIP as the service_locahzation_function. Therefore, the receiver can immediately derive 
on which cell_id the signalled SH service is being transmitted. 

EXAMPLE: SHIP detailed in table 5 gives the regionalization information for a case where we have 2 common 
SH service (id = and id = 1) sent on a unique cell (cell_id = 0), and 2 additional local SH service 
sent on 10 local cells (cell_id from 256 to 265). The signalling is done using 1 1 different multicast 
groups (1 to 11) for the 11 different regions (1 for the global region, 10 for the local regions). 
Therefore the individual_addressing_scheme is set to multicast mode. 

Table 5: Example of SHIP with SH_service_localization function 



SH framejnitializationjjacket individual iteration bits bytes value(dec) value 



remarks 



transport jDacket_header 


32 


1 


32 


4 




synch ronizationjd 




8 


1 


8 


1 




sectionjength 




8 


1 


8 


1 


178 


Rd inter 




16 


1 


16 


2 




period icjiag 




1 


1 


1 


0,125 




future_use 




14 


1 


14 


1,75 




SH_use 




1 


1 


1 


0,125 




syn ch ro n i zati nji m e_ 


.stamp 


24 


1 


24 


3 




maximum_delay 




24 


1 


24 


3 




tps_ship 




32 


1 


32 


4 




individual_addressing 


Jength 


8 


1 


8 


1 


255 


Global txjoop 














txjdentifier 




16 


1 


16 


2 


1 


functionjoopjength 




8 


1 


8 


1 


10 


celljd 




40 


1 


40 


5 





ser vi cej o ca 1 i zati o n_f u n cti o n 


40 


1 


40 


5 





Local txjoop 














txjdentifier 




16 


10 


160 


20 


2 


functionjoopjength 




8 


10 


80 


10 


120 


celljd 




40 


10 


400 


50 


256 


servicejocalization Junction 


56 


10 


560 


70 


2 


crc_32 




32 


1 


32 


4 




stuffing_byte 




8 














0xB2 Sze is 1 78 bytes, enabling to determine the number of iterations 
in txjoop when multicast addressing is used 



OxFF multicast addressingis used 



0x0001 multicast address equals 1 for 1 global region 
0x0 A 1 < max value 255 / OxFF bytes 
0x00 celljd for 1 global region 
0x00 2 global SH services are signaled 
SH_serviceJd varies from to 1 



0x0002 multicast address from 2 to 1 1 for the 10 local regions 

0x78 1 20 < max value 255 / OxFF bytes 
0x0100 celljd 256 to 265 for the 10 local regions 
0x02 2 global service(s) and 2 local service(s) are signalled at each iteratio 
Global: 2 ids from to 1 
Local: 2 ids from (2+ k*2) to (3+ k*2) where k is selected in [0;9], 



1504 188 

In this example, there are 1 1 txjdentifier iterations, one for each multicast group / cell: 

• Multicastjd 1 / celljd 0: 

This group refers to the satellite cell (celljd 0) where multicast group 1 configures the unique satellite 
transmitter. 

NOTE: Individual addressing is not possible when there are other multicast groups being signalled for local 
repeaters. 

2 SH_services (SH_services and 1) are signalled on this cell, no local SH service is signalled. 

Not only the transmitter is configured but also the receiver, since the receiver can now attach 
SH_services and 1 to celljd 0. 

• Multicastjd 2 to 1 1 / celljds 256 to 265: 

These groups refer to the 10 local cells (id 256 to 265). 

Different multicast groups are used to signal this information (from address 2 to 11). 

Inside every terrestrial cell, the 2 common SH_services (id to 1) are signalled so that every local 
transmitter repeat the 2 common SH_services, in addition to a unique local SH_service selected among 
the 10 possible. 
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In the simple case of 1 common SH service and 1 local SH service per region, the maximum number of regions that 
enable to send all signalling in 1 DVB packet of payload size 184 bytes is around 10. If more regions are needed, the 
repeaters can be grouped in different multicast groups, or signalling can be split in successive SHIP packets according 
to rules described in clause 4.10.2.1. 

4.10.2.5 Service_synchronization_function 
4.10.2.5.0 Introduction 

The service_synchronization_function MUST be present in the following cases: 

• Case 1 : When diversity is used at SH service layer (diversity_mode XNOR '1 1 10' = '1 1 11') to signal SH 
services delineation to both transmitters and receivers. 

• Case 2: When class 2 physical interleaver is used to signal SH service delineation to transmitters and receivers 
for power saving and memory reduction (see [7], clause 7.2.3.3.1). 

• Case 3: The service_synchronization_function MAY be present when the number of SH frames per 
superframe is lower than 1 since other means can be used to synchronize transmitters (see [7], 
clause 7.5.1.2.2). 

Depending on each case, the following requirements are put on service_synchronization. 

Table 6: service_synchronization_function requirements 



Constraint/ 
Case 


Number of SH 
services 


Individual SH 
service 


Sum of SH services 


Example 


1 (diversity at SH 
layer) 


At least equal to 
the sum of global 
and local regions 


In each region, 

one SH service 

MUST start a SH 

frame and end an 

SH frame 


The SH services have a 
repetitionjnterval which is a 
multiple of SHJrame duration 


See clause 
4.2.1.3 


2: long PHY 

interleaver with 

time slicing) 


Inferior or equal 

to the number of 

time-slice 

services 


Non specific 


The SH services have a repetition 

interval equal to the repetition 

period of the physical interleaver, 

itself being a multiple of SH 

frames 


See [7], 
clause 7.2.3.3.1 


3: transmitter 
synchronization 


At least 1 


Non specific 


The cumulated length of all SH 

services MUST be higher or equal 

in size to the number of 

EFRAMES per Superframe 


See [6], 
clause A.4.9 



This service_synchronization_function enables to discover how SH services are actually organized at the level of 
EFRAMES in the TS. This function is therefore useful for both transmitters and receivers since both need to discover 
the SH services distribution. How the service_localization_function is signalled depends on the case: 

• In case of content regionalization (case 1 of table 6): 

If the synchronization_function is located on the common part, the service_synchronization_function 
MUST be complete and MUST list all SH services present in the complete TS in their sending order. 

If the synchronization_function is located on the local part, the service_synchronization_function MUST 
list only the common and current local service(s) in their sending order, all services being not transmitted 
in this local TS MUST not be hsted. 

• In case 2, in addition to the previous rule, the individual time-slices services MUST also be listed in their 
sending order. 

• In case 3, no specific rule is required. 

4.10.2.5.1 txjdentifier 

Same rules as clause 4.10.2.4.1 apply. 



ETSI 



65 



ETSI TS 102 470-2 V1.1.1 (2009-12) 



4.10.2.5.2 



Cell id 



Cell_id is not mandatorily required since the information is TS dependent (if the receiver catches the 
service_synchronization_function, this means it can receive the signalled services, except for the common part for 
which the service_localization_function MUST be used). However for simplification purposes, the same SHIP can also 
provide binding information between the service_synchronization_f unction and the receivers, the cell_id function 
MUST be used in the same SHIP as the service_localization_function. Therefore, the receiver can immediately derive 
on which cell_id the signalled SH service is being transmitted. 

EXAMPLE: For instance the SHIP detailed in table 7 gives the service description information on a SHIP 
located on the common part for a case where we have the maximum possible number of SH 
service sent on a unique cell (cell_id = 0). As can be seen, up to 75 services MAY be signalled in a 
unique SHIP. 

Table 7: Example of SHIP with a service_synchronization_function 



SH framejnitializationjaacket 


individual iteration bits 


bytes 


value(dec) 


value 


remarks 


transportjDacket_header 


32 


32 


4 








synchronizationjd 


8 


8 


1 








sectionjength 


8 


8 


1 


178 


0xB2 


Sze is 1 78 bytes, enabling to determine the number of iterations 


Fb inter 


16 


16 


2 






in txjoop when multicast addressing is used 


periodicjiag 


1 


1 


0,125 








future_use 


14 


14 


1,75 








SH_use 


1 


1 


0,125 








synchronization_time_stamp 


24 


24 


3 








maximum_delay 


24 


24 


3 








tps_ship 


32 


32 


4 








individual_addressing_length 


8 


8 


1 


255 


OxFF 


multicast addressing is used 


Global txjoop 














txjdentifier 


16 


16 


2 


1 


0x0001 


multicast address equals 1 for 1 global region 


functionjoopjength 


8 


8 


1 


160 


OxAO 


1 60 < max value 255 / OxFF bytes 


celljd 


40 


40 


5 





0x00 


celljd for 1 global region 


service_synchronization_function 


1240 


1240 


155 





0x00 


75 global SH services are signaled 



crc_32 
stuffing_byte 



32 



32 




1504 16 



4.11 Signalling field 



Signalling field is defined in [6], clause 5.5.5.2. Its usage is refined in this clause. 

The signalling field MUST be used to signal the cell_id via the field transport_stream_identifier. The 8-bit field enables 
to signal a value between and 255 which are the allowable values for satellite cell_id. 
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